Fostering innovation in an organization requires a skilled and structured approach. If you can’t see how different systems within your company – both business and technological – work together to reach your goal, don’t be surprised when IT projects don’t deliver their sought-after value. Just like any transformative change, modernization requires a holistic and systematized approach, a groundwork for every stage of this gradual process.
Enterprise architecture is the roadmap – the practice that encompasses the assessment, planning, and designing of your business’s use of technology to achieve its goals. The people responsible for this seamless transition are enterprise architects. Their broad range of skills along with their ability to find a common language with both stakeholders and IT experts allow them to guide a company to its desired state. We’ve already discussed the role of enterprise architects in business and now we’ll highlight the tools and approaches they put to work in planning and visualizing the transformation.
Enterprise architecture considers organizations complex systems. To manage this complexity, enterprise architects use standardized methodologies or frameworks that help them document a system’s behaviors in a commonly recognized way. Let’s quickly compare the most popular frameworks.
Now, we’ll dive deeper into functionalities and use opportunities for each framework. Read on to learn how you can apply them for your organization.
The TOGAF’s established method for rapidly developing an architecture (Architecture Development Method or ADM) is a step-by-step process that describes ten phases arranged in a cycle. In the center of the process you can find Requirements Management – the stage reflecting the ongoing process of aligning changes and requirements of each phase.
This two-dimensional matrix consists of six rows (perspectives) and columns (fundamental questions), its intersecting cells describing representations of the enterprise in a detailed and structured way. Zachman Framework is normalized, and its rows and columns cannot be removed to keep the holistic overview of the system. Still, it’s flexible enough to work for a project of any scope to clearly focus on each element and its purpose, and build contextual relationships between cells. The finished scheme is not an architecture; it’s a tool helping manage and organize one.
Executive Perspective - a planner seeking information about a system’s size and costs Business Management Perspective - an owner wanting to know how business processes interact Architect Perspective - an architect determining how software functions represent the business model Engineer Perspective - a contractor applying specific technologies to solve business problems Technician Perspective - a programmer given instructions Enterprise Perspective - an operational system itself
The columns can be described as:
What? - enterprise data each row has to deal with How? - an organization’s functions and processes Where? - geographical locations, logistics, interconnections When? - business cycle and events triggering business activities Who? - organizational units and interaction between people and technology Why? - the translation of business goals and strategies into specific means
SABSA closely follows the Zachman Framework and is adapted to a security focus. SABSA uses Zachman’s six questions that we’ve already described to analyze each of its six layers of security architecture development.
It’s four main views are described as:
Logical - represents what a system should functionally provide, system components and their relationships Process - shows a system’s performance, scalability, workflow rules Development - focuses on software modules, packages, and environments used Physical - considers how software is mapped to hardware
The fifth view – Scenarios or Use Cases – represents the high-level view of the whole system and illustrates an architecture’s consistency and validity. This view is relevant for all stakeholders.
Unified Modeling Language (UML) is a descriptive visual language providing scalable diagrams used for standardizing software development. It’s easily expandable and customizable for different business domains using an extension mechanism – UML Profile. Enterprise architects use stereotypes, tagged values, and constraints to tailor the language to specific environments thus ensuring that the finished model will address corporate-specific requirements.
Some generic UML diagrams include the Deployment Diagram, visualizing a system’s execution architecture; the Activity Diagram, that models behaviors of the system and how these behaviors are related; and the Sequence Diagram, representing workflows and cooperation.
These concerns don’t necessarily mean that three decades of practice has led to EA frameworks becoming obsolete. Just like any formalized approach, Zachman or SABSA are criticized and augmented, introduced at the beginning and throughout the process, and used by enterprise architects in different ways. Be sure to take the most advantageous elements of a framework and work around the constraints.
When looking for an enterprise architecture practice, note their experience and capabilities outside the TOGAF certification and listen to their recommendations regarding frameworks and tools relevant to your particular case.
Enterprise architecture is the roadmap – the practice that encompasses the assessment, planning, and designing of your business’s use of technology to achieve its goals. The people responsible for this seamless transition are enterprise architects. Their broad range of skills along with their ability to find a common language with both stakeholders and IT experts allow them to guide a company to its desired state. We’ve already discussed the role of enterprise architects in business and now we’ll highlight the tools and approaches they put to work in planning and visualizing the transformation.
Enterprise architecture considers organizations complex systems. To manage this complexity, enterprise architects use standardized methodologies or frameworks that help them document a system’s behaviors in a commonly recognized way. Let’s quickly compare the most popular frameworks.
Now, we’ll dive deeper into functionalities and use opportunities for each framework. Read on to learn how you can apply them for your organization.
TOGAF - a Standard Framework for Continuous Architecture Development
The Open Group Architecture Framework or TOGAF has been developed by more than 300 enterprise architects from leading companies including Dell, Cognizant, and Microsoft. TOGAF development traces back to 1995 and its current version 9.1 embodies all improvements implemented during this time. The tool has a common vocabulary and is meant to support all levels of architecture for enterprises both large and small.The TOGAF’s established method for rapidly developing an architecture (Architecture Development Method or ADM) is a step-by-step process that describes ten phases arranged in a cycle. In the center of the process you can find Requirements Management – the stage reflecting the ongoing process of aligning changes and requirements of each phase.
TOGAF Architecture Development Method
What do its elements represent?
Preliminary Stage - defining the principles, concerns, and requirements for a future architecture Architecture Vision - choosing architecture scope and methodologies to align with stakeholders Business Architecture - using modeling methods to describe an Architecture Vision Information Systems Architecture - modeling Data and Application Architecture Technology Architecture - transforming the description of a system into the basis of architecture implementation Opportunities and Solutions - defining the main steps towards changing your current architecture to the target one, the basis of the Implementation Plan Migration Planning – describing the estimated costs, timeline, and roadmap of implementation Implementation Governance - assigning governance functions for different stages of architecture deployment Architecture Change Management - providing monitoring for technology and business changesWhen would you use TOGAF?
- To transform an organization’s architecture and processes in a controlled manner
- To repeatedly align your processes with current goals
- To support an architecture development process at all stages, from evaluation of key requirements to actual implementation
Zachman Framework - a Cross-Dimensional Matrix to Align Roles and Ideas
The Zachman Framework is not a methodology but rather a template describing how different abstract ideas are viewed from different perspectives.This two-dimensional matrix consists of six rows (perspectives) and columns (fundamental questions), its intersecting cells describing representations of the enterprise in a detailed and structured way. Zachman Framework is normalized, and its rows and columns cannot be removed to keep the holistic overview of the system. Still, it’s flexible enough to work for a project of any scope to clearly focus on each element and its purpose, and build contextual relationships between cells. The finished scheme is not an architecture; it’s a tool helping manage and organize one.
Zachman Framework Source: NoMagic
What do its elements represent?
The players represented in rows are:Executive Perspective - a planner seeking information about a system’s size and costs Business Management Perspective - an owner wanting to know how business processes interact Architect Perspective - an architect determining how software functions represent the business model Engineer Perspective - a contractor applying specific technologies to solve business problems Technician Perspective - a programmer given instructions Enterprise Perspective - an operational system itself
The columns can be described as:
What? - enterprise data each row has to deal with How? - an organization’s functions and processes Where? - geographical locations, logistics, interconnections When? - business cycle and events triggering business activities Who? - organizational units and interaction between people and technology Why? - the translation of business goals and strategies into specific means
When would you use Zachman Framework?
- To concentrate on independent objects without losing the vision of the holistic perspective and relationships between objects
- In conversation with stakeholders to clarify what each level should focus on without delving into technical aspects
- As a documentation tool that can be easily combined with other models
- To simplify communication within the team
- To look at what perspectives you’ve already described and what’s missing
SABSA - a Risk Management Framework to Align Business and Security
SABSA (Sherwood Applied Business Security Architecture) is an operational risk management framework that includes an array of models and methods to be used both independently and as a holistic enterprise architecture solution. This is another highly customizable and scalable framework – it can be adopted in a small scope and then incrementally implemented on an enterprise-wide level.SABSA closely follows the Zachman Framework and is adapted to a security focus. SABSA uses Zachman’s six questions that we’ve already described to analyze each of its six layers of security architecture development.
SABSA’s six layers of security architecture
When would you use SABSA?
- To avoid mistakes by documenting them in advance and keeping them in mind while creating an architecture
- To align your security architecture with business values
- To set up quantifiable metrics that track business performance rather than technical ones
The 4+1 View Model - a Minimalist Tool for Addressing Different Stakeholders
The basic idea behind the 4+1 methodology lies in dividing different aspects of software systems based on the interests of different stakeholders. This is another framework that resembles Zachman’s approach. The model’s creator Philippe Kruchten believed that by separating an architecture into distinct views, it will be displayed from a viewpoint of each stakeholder, be it a customer or a developer.It’s four main views are described as:
Logical - represents what a system should functionally provide, system components and their relationships Process - shows a system’s performance, scalability, workflow rules Development - focuses on software modules, packages, and environments used Physical - considers how software is mapped to hardware
The fifth view – Scenarios or Use Cases – represents the high-level view of the whole system and illustrates an architecture’s consistency and validity. This view is relevant for all stakeholders.
Scenarios or Use Cases view of the 4+1 framework
When would you use the 4+1 model?
- To prioritize different views and simplify the organization process
- To integrate with other tools such as TOGAF
- To easily document both individual projects and a company’s whole IT architecture
Creating a custom EA Framework using Unified Modeling Language (UML)
Most enterprise architecture frameworks offer a limited number of viewpoints and aspects, so it’s reasonable and common to use them in combination. None of the proposed models can include all measures and meet every organization’s needs. However, this allows enterprise architects customize documentation and create an independent overview of a system.Unified Modeling Language (UML) is a descriptive visual language providing scalable diagrams used for standardizing software development. It’s easily expandable and customizable for different business domains using an extension mechanism – UML Profile. Enterprise architects use stereotypes, tagged values, and constraints to tailor the language to specific environments thus ensuring that the finished model will address corporate-specific requirements.
Some generic UML diagrams include the Deployment Diagram, visualizing a system’s execution architecture; the Activity Diagram, that models behaviors of the system and how these behaviors are related; and the Sequence Diagram, representing workflows and cooperation.
An example of an Activity Diagram Source: SparksSystems
UML models allow businesses to develop a set of processes and use cases to visualize an enterprise architecture overall and each system within it. It’s a complicated tool that requires training to operate and adjust to a company’s needs, but the benefits of this approach are correlated with the enterprise architect’s effort.The problems with EA frameworks
Almost 30 years after the creation of the Zachman Framework – the oldest of the currently used EA tools – a question has arisen: Do frameworks bring any value or do they cause harm? Here are the main concerns surrounding the use of enterprise architecture frameworks today.- Documentation is not comprehensive
- They are time-consuming and lack flexibility
- Complete integration is impossible
These concerns don’t necessarily mean that three decades of practice has led to EA frameworks becoming obsolete. Just like any formalized approach, Zachman or SABSA are criticized and augmented, introduced at the beginning and throughout the process, and used by enterprise architects in different ways. Be sure to take the most advantageous elements of a framework and work around the constraints.
Conclusion
Enterprise architecture frameworks are valuable for planning and visualization. They are especially helpful at the early stages of architectural change to lead the conversation with stakeholders and visualize the outcomes of business and IT alignment. However, they are still just toolkits for people responsible for preparing the roadmap to change.When looking for an enterprise architecture practice, note their experience and capabilities outside the TOGAF certification and listen to their recommendations regarding frameworks and tools relevant to your particular case.