Learning And Building Your Enterprise Architecture Framework
Modern day businesses rely heavily on information technology (IT) throughout every single department and discipline. Sales, marketing, customer service, data collection, data analysis — all of this requires IT. Not only does your organization require dozens if not hundreds of IT solutions (including hardware, software, networks, and more), but that technology must be able to function together so that your business processes are efficient and effective — and that your customer experience goes as smoothly as possible.
To not only ensure that all of your technology is working together in the most efficient and effective way possible, but that you are able to adapt to emerging technologies and identify IT solutions that will benefit your business in a cost-effective way, you need a comprehensive approach that provides a big view picture of your entire organization. This is where enterprise architecture comes in. By building an effective enterprise architecture framework, your ability to execute your business strategies and achieve your business objectives will increase dramatically.
What is Enterprise Architecture?
Pinpointing exactly what enterprise architecture is can be difficult. There is no single definition, just an understanding of what it encompasses. It’s a blueprint that defines the structure and operation of an organization and provides a comprehensive view of how business, technology, and information work together. It’s also the practice of promoting a healthy IT infrastructure that enables successful business practices. Finally, it’s a set of models and diagrams that describe the structure of your organization.
Through enterprise architecture planning, you will be able to analyze, design, plan, implement, and integrate the IT solutions you need to achieve your business objectives and goals.
Brief History
While the first enterprise architecture framework was published by John Zachman in the 1980s, the origins of enterprise architecture can be traced further back. Below is a brief history of enterprise architecture and how it evolved to where it is today.
Pre EA
Prior to Zachman’s framework, IBM formalized its BSP(Business Systems Planning) methodology, which included a top-down planning approach as well as an architecture planning process, which was divided into a number of steps to help guide companies. The plan included diagrams and matrices that helped illustrate the system. Even today, elements of the BSP methodology are found in modern enterprise architectures. However, IBM’s BSP focused solely on IT infrastructure.
Early EA
The early EA period ran through the 1980s and early 1990s. The term “enterprise architecture” became widely accepted during this time. Some of the earliest framework theories include the Zachman Framework, the PRISM framework, and the NIST(National Institute of Standards and Technology) enterprise architecture. The approach changed in the early 1990s with the introduction of Steven Spewak’s Enterprise Architecture Planning framework, which had a lot in common with the earlier BSP methodology, and the TAFIM (Technical Architecture Framework for Information Management) model. Both of these frameworks addressed the fact that modern systems were becoming more complex by including data integration and applications.
Modern EA
The modern EA period started in the late 1990s and continues to this day. Many newer frameworks, such as the FEAF (Federal Enterprise Architecture Framework), are based on Spewak’s Enterprise Architecture Framework, while others, such as TOGAF (The Open Group Architecture Framework), are based on TAFIM. Modern frameworks provide solutions beyond IT and focus on integrating every part of an enterprise, including an organization’s IT infrastructure, applications, business needs, and overall business strategy.
Benefits Of A Well-Structured EA
A good enterprise architecture will help your organization align its IT strategy, technology, and business needs with its business strategy. The most effective enterprise architectures will help to translate your business strategy (which can sometimes be vague) to practical plans and actions and leverage them into solutions that will help you achieve your business strategy.
Aligning your business needs across every department and discipline within your organization helps you identify actual business motives and drivers and pinpoint strengths and weaknesses throughout your company. Of course, this is all still very broad. Some specific ways in which your business can benefit from a well-structured enterprise architecture follow:
Efficient Operation
Enterprise architecture can improve the efficiency of operations throughout your organization in a number of ways, like identifying and eliminating inefficient processes between incongruent systems, implementing better practices to simplify maintenance requirements, or standardizing your tech platforms. All of this can help to reduce current costs, get your product to market faster, and improve the customer experience.
Effective Process
Enterprise architecture can empower you to analyze your business processes and identify how they are performing, whether they need to be redesigned, and how they can be improved if a redesign is required. By improving the effectiveness of your processes, you’ll improve productivity, reduce miscommunication, and improve the overall results.
Creates Opportunities
Enterprise architecture allows you to align your business strategies with your IT. This, in turn, makes it easier to identify and analyze new opportunities, whether in the form of potential future revenue generation or the implementation of new strategic initiatives. Enterprise architecture frameworks can help you assess how business changes are affecting or might affect your organization.
Automated Efficiency
Enterprise architecture can be used to align your technology planning with your business strategies. For example, you would be able to assess how new systems and emerging technologies can impact your business and benefit your company by focusing on the strategic use of specific technologies.
Framework Vs. Methodology
When researching enterprise architecture, you’re likely to run into the terms “framework” and “methodology” quite often. They may even seem like they are interchangeable. In fact, they are terms that are often used interchangeably; however, they are not the same thing.
Framework
A framework is a structure used to organize information. It’s what defines the enterprise architecture’s scope and how everything within the structure relates to one another. Think of it as a static model that can clarify and integrate a range of models, concepts, techniques — and methodologies. Many of the most commonly used frameworks incorporate some kind of methodology.
Methodology
The methodology is the system of guidelines used to solve a problem. It can include components such as methods, tasks, tools, and techniques.
Some of the Most Popular EA Frameworks
Now that you have a clearer idea of what enterprise architecture is and what a framework consists of, the following are some of the most popular frameworks commonly used by enterprises throughout the U.S.
TOGAF
TOGAF is without doubt the most popular enterprise architecture framework currently on the market. An estimated 80 percent of Global 50 companies and 60 percent of Fortune 500 companies use TOGAF. Although free to use for internal purposes, organizations who want to use TOGAF for commercial purposes will have to pay for it. TOGAF was created by The Open Group to improve communication across organizations by introducing a common vocabulary for everyone to use, standardizing open methods for enterprise architecture (avoiding lock-in to proprietary framework solutions), achieve a measurable ROI, and help businesses to use their money and time more efficiently and effectively.
Like many frameworks, the main purpose of TOGAF is to help companies align their IT goals with their business goals in addition to assisting with the organization of cross-departmental IT efforts. TOGAF has four architectural domains, including business, applications, data, and technical architecture, that provide specializations for companies.
Zachman
The Zachman Framework for Enterprise Architecture and Information Systems Architecture was created by John Zachman in 1987. The framework collects and refines principles from older methods. It consists of a 36-cell table with six rows and six columns. The rows include business model, components, technology model, scope, system model, and working system. The columns include who, what, why, where, when, and how.
The main purpose of the Zachman framework is to provide a comprehensive representation of an IT enterprise using a logical structure that allows multiple perspectives and categorization of business artifacts.
FEAF
FEAF is a framework developed in 2006 by the U.S. federal government as a way to organize its many different agencies and organizations. It’s predecessor, also known as FEAF, was developed in 1996 in response to the Clinger-Cohen Act. The Clinger-Cohen Act established the need for federal agencies to implement effective IT throughout their organizations. Although built by the government for government agencies, private companies can make use of it as well. In fact, because FEAF was built as a foundation for a massive restructuring of federal agencies, its framework will provide a strong foundation for future companies.
The FEAF model is based on the Zachman framework as well as TOGAF. FEAF consists of five reference models that include business, components, data, service, and technical models. Combined, they create a segment model that outlines for the user the best way to install enterprise architecture.
DoDAF
The DoDAF (Department of Defense Architecture Framework) was built by the U.S. Department of Defense (DoD) that addresses stakeholder concerns with visualization infrastructure using viewpoints that are organized by different views, including visualizing, understanding, and assimilating the scope and complexities of the description of an architecture through numerous methods. These methods include alternative conceptual, behavioral, graphical, ontological, pictorial, probabilistic, tabular, and temporal means. Considering that this framework was built for the DoD, it shouldn’t be a surprise that the DoDAF is particularly appropriate for addressing complex interoperability and integration challenges facing bigger systems.
Gartner
Technically speaking, Gartner is not a framework. Instead, it’s a methodology created by Gartner (one of the world’s leading IT research businesses) that includes the best practices for enterprise architecture planning (as established by Gartner and adapted into their own consulting practices). Although it does not conform to the structures of frameworks, models, or taxonomy, it is recognized as a practical methodology focusing on business outcomes with few steps or components by CompTIA (Computing Technology Industry Association).
The Gartner methodology focuses on maintaining a constant state of adapting to your surrounding environment. Instead of building the webs of a framework or developing a single process, the Gartner methodology relies on constant recorrection, thereby allowing the three core entities (business owners, technology implementors, and information specialists) to address any challenge.
Other EA Frameworks
While the previously mentioned frameworks are some of the most popular, there are many more frameworks to choose from. You can even put together a hybrid framework using components from different frameworks to create a more customized enterprise architecture. Some of the other enterprise architecture framework options that you can use include:
Proprietary
There are many frameworks built specifically by IT organizations for their clients (the Gartner framework is a proprietary framework, for example). However, you will have to pay for it. Proprietary frameworks available for purchase include:
- ASSIMPLER – The ASSIMPLER (Availability, Scalability, Security, Interoperability, Maintainability, Performance, Low cost of ownership, Extendability, Reliability) framework derived from the work done by Mandar Vanarse.
- CLEAR – The CLEAR (Clarifying Learning Expectations and Results) framework was built for small and medium-sized organizations by Atos Origin.
- IFW – The IFW (Information FrameWork) was built in 1996 by Roger Evernden as an alternative to the Zachman framework.
- IAF – The IAF (Integrated Architecture Framework) was built in 1993 by Capgemini in France.
- OBASHI – The OBASHI (Ownership, Business, Processes, Applications, Systems, Hardware, Infrastructure) framework was built by APMG in England.
- SAP’s – The SAP (Systems, Applications, Products) framework is based on the TOGAF model and was built primarily to support the adoption of SOA (Service Oriented Architecture).
- SAM – The SAM (Solution Architecting Mechanism) framework is a service-oriented framework built for eServices and that is composed of three core pillars, including design methods, systematic process, and solution patterns.
Open-Source
- LEAD – LEAD (Layered Enterprise Architecture Development) is the only framework available that’s both open source and community-based whose foundation is the international standards that are still being used today.
- MEGAF – MEGAF is an infrastructure that allows you to realize architecture frameworks that focus on reusing pre-defined viewpoints and languages, and that complies with the definition of architecture framework established in ISO/IEC/IEEE 42010 (the international standard for architecture descriptions of systems and software).
- Praxeme – Praxeme is an open enterprise methodology that focuses on all aspects of an enterprise, from strategy to deployment, using various modeling approaches.
- SABSA – The SABSA (Sherwood Applied Business Security Architecture) framework was built for service management and enterprise security architecture. It uses a risk-based methodology that focuses on integrating security into business and IT management.
- TRAK – TRAK is a systems-oriented framework that has roots that can be traced back to the British MODAF (Ministry Of Defense Architecture Framework).
Group-Developed
Group-developed frameworks were built through collaboration by multiple organizations. The most well-known group-developed framework is TOGAF; however, it’s not the only one. Several other group-developed frameworks include:
- ARCON – ARCON (A Reference for Collaborative Networks) is a framework that’s based on networks of enterprises instead of a single enterprise.
- Dragon1 – Dragon1 is a visual enterprise architecture method that’s recognized as a framework by The Open Group.
- EABOK – EABOK (Enterprise Architecture Body Of Knowledge) is a federally funded guide to enterprise architecture developed by MITRE’s Center for Innovative Computing and Informatics.
- IDEAS Group – The IDEAS (International Defence Enterprise Architecture Specification) Group consists of four countries that collaborated together to build a common framework and ontological system for interoperability.
- RM-ODP – The RM-ODP (Reference Model of Open Distributed Processing) framework was created by ISO (International Standards Organization) and ITU-T (International Telecommunication Union – Telecommunication) for building the requirements of open-distributed systems.
Government
The government often develops its own frameworks to meet the specific needs of their various agencies. The following are some of the other government developed frameworks that are available:
- GEA – GEA (Government Enterprise Architecture) is the standard framework used by departments of the Queensland Government.
- FDIC – The FDIC framework was built for the FDIC (Federal Deposit Insurance Corporation) and was based on both federal and industry best practices.
- NIST – NIST (National Institute of Standards and Technology) developed the NIST framework in the late 1980s. It was promoted by the U.S. government as the foundation for enterprise architectures of government agencies throughout the U.S. in the 1990s.
- NORA – NORA (Nederlandse Overheid Referentie Architectuur – or Dutch government reference architecture) is the framework created by the Dutch government.
- TEAF – TEAF (Treasury Enterprise Architecture Framework) was built for the U.S. Department of the Treasury.
Defense Industry
Countries all over the world have frameworks that were specifically developed for their respective defense agencies. The DoDAF being the one used in the U.S. Some of the other defense industry frameworks from around the world are below:
- AGATE – AGATE is the framework built by the France DGA (Direction générale de l’armement), which is the French government agency responsible for developing and evaluating weapon system programs..
- DNDAF – DNDAF is the framework designed by the DND/CF (the Department of National Defense and Canadian Forces).
- MODAF – MODAF is the framework built by the UK Ministry of Defence.
- NAF – The NAF is the framework designed by NATO (North Atlantic Treaty Organization).
Planning Your Enterprise Architecture
Now that you have a good idea about the various frameworks that you can use for your enterprise architecture, the next step is to learn how to plan your enterprise architecture. We encourage following these steps when planning your organization’s enterprise architecture:
1. Process Initiation
The process initiation stage marks the beginning of your project. It’s during this stage that you will get organized by scoping the project, setting up your development team, and establishing your target vision.
Plan The Scope of your Project
For an enterprise architecture to be most effective, it should encompass the whole of your company. However, it may be necessary to prioritize specific problem areas and pursue a phased approach. The scope can also be limited to the current components of your organization or can address a future strategic direction as well. Only you can determine the breadth and the depth — both of which will rely heavily on your specific company and your company’s specific needs.
Build Your Team
Once you’ve defined the scope of your project, you will need to put together a team of developers. Generally speaking, your team should have between four and six developers — all of which must be able to focus solely on your enterprise architecture project. These developers will make up your core team, led by a chief system architect whose job it is to provide focused guidance and to successfully address unforeseen challenges that will arise throughout implementation. The chief system architect is also responsible for determining how your company views its IT.
Your team will also need experts in the domains that will be affected by the architecture as they can provide specialized knowledge to your team. For smaller projects, you may only need a few experts. If you’re restructuring an entire system for a large company, you will need between four and six experts. For massive projects involving 50 to 100 systems, it’s not uncommon for 50 to 100 functional experts to work on the project part-time.
Establish Your Target Vision
Finally, a target vision clarifies what the goal of the project is and keeps everyone on the same page (including team members as well as other stakeholders) and the project on track. One of the biggest challenges facing enterprise architecture planning is a lack of a shared vision. There are several questions that you will need to answer to formulate a target vision:
- Who are the stakeholders?
- What problems are you trying to solve?
- How should those problems be prioritized?
- What documentation and publishing standards will you use?
- What tools will you use?
- Where will your team work?
To establish a target vision, consider setting up an architecture steering committee composed of domain experts and high-level managers from the functional areas. Every area of your organization that the architecture crosses should have a representative on the committee.
2. Characterize Your Baseline
Once you’ve initiated the process by following the previously listed steps, you’ll need to characterize your baseline. This involves describing your enterprise’s existing information systems and their components — as well as assessing their relationships. Many organizations make the mistake of skipping this step; however, you can’t implement a new architecture if you don’t know what your existing architecture is. By characterizing your baseline, you will be able to identify assets you didn’t know about, perform gap analysis, identify redundancies, classify your IT-related business assets, figure out who is using what and why, and manage business costs.
3. Develop Your Target Architecture
After characterizing your baseline architecture, you can now develop your target architecture or the vision for your enterprise’s future information systems. This vision should describe how your systems will work together to support your business operations in the future through the implementation of enhancements that will add new functions vital to your existing and new operations.
Essentially, your target architecture describes what your enterprise wants to be and not what it currently is. However, it shouldn’t be limited to just being an update of your existing architecture (your baseline). Think of it more as a formalization of your target vision based on the views that are used to characterize your baseline architecture.
4. Plan Your Transition
Once you’ve developed your target architecture, it’s time to plan how to transition from your baseline to your target. This will require creating a plan consisting of a comprehensive set of initiatives that are sorted by strategic value. All projects will need to be completed and prioritized, which can cause some friction within the organization and why commitment from senior management is so important (and why it helps to have a committee in place).
5. Develop And Implement
The last step is implementation. While you would expect this to go smoothly, especially after defining your target architecture and developing a comprehensive transition plan, it’s important to understand that your enterprise architecture will always be evolving. You can help ensure that your architecture stays close to your business requirements as you implement it by planning for how to address inevitable changes, such as changes in technology, changes in the schedule, and changes in your budget.
Effect of Stakeholders’ View on Its Development
Different stakeholders see the architecture differently. This requires accommodating all of their views by representing the architecture in different ways. Consider these different stakeholders, their views, and how you may need to accommodate those views:
Customer
Because it’s the customers that pay for the effort, it is their views that will help you to identify the scope of the architecture. They are also interested in how the architecture will aid in the growth of your organization and therefore also help in serving as a basis for acceptance criteria. Customer views can also help you with other important facets of enterprise architecture planning, such as determining the schedule, budget, feasibility, and risk of the project. Note that customers will want to view functions at a high level, so the architecture must be understandable at that level through high-level focused models.
User
Since the users will be using the systems developed from your architecture, they will want to know how the architecture will address their needs. Users can help you validate the performance, interoperability, and performance of the architecture. Because users will only need to see enough detail to identify whether the system will work as intended, you can accommodate them in the same way you can accommodate your customers — with high-level focused models.
System Architects
It’s the system architects who will determine the definition of the architecture. They will need to trace the requirements to the development of individual systems. They will help to assess the correctness, consistency, coherency, and completeness of the architecture. They will require more detailed descriptions of the architecture to do this.
System Developer
Based on the architectural definition provided by the system architects, the system developers will build the individual systems. They are responsible for choosing and assembling components as well as for evaluating and maintaining interoperability with your existing systems. To do this, they will need to reference the architecture, which means that like the system architects, they will also need more detailed descriptions of the architecture.
System Maintenance
Finally, the engineers are responsible for system maintenance. They help to evolve the architecture by using it to guide system and software modification as well as evaluating and maintaining interoperability with your organization’s existing systems. They too will require more detailed descriptions of the architecture.
Bringing Value To Your Business
Enterprise architecture is a valuable management solution that not only helps you understand and support your business processes, applications, information, and technical infrastructure, but that also helps you align long-term business objectives and goals with the strategic use of technology — in addition to assessing the impact of business changes across your organization. Through enterprise architecture, you can improve your organization’s efficiency and effectiveness across all departments and significantly improve your chances of success.
Need assistance with creating your enterprise architecture framework? Our team of experts would be glad to help. Contact us today.
