I am trying to summarize the discussion we had and maybe someday I might actually go back and refresh the entire details.
Zachman Framework.
I agree with the general perception that this is not really a framework. It doesn't define an actual framework for Enterprise architecture. It's simply a taxonomy for organizing architectural artifacts.
These artifacts are important elements in the enterprise architecture and they define the different representations of the Enterprise from different stakeholders perspectives.
There are basically two dimensions in Zachman framework. One dimension is the various actors in the scheme. Using the building industry as an example, the actors could include the owner, the builder etc. Different artifacts are actually needed for each of these actors. Quoting Zachman, "These architectural representations differ from the others in essence, not merely in the level of detail". There are 6 actor perspectives viz; contextual(planner), conceptual(owner), Logical(designer), Physical(subcontractor) and Detailed(enterprise).
The second dimension is the descriptive focus of the artifact. Zachman proposed six descriptive foci; the What(data), Where(Network), When(time), Why(Motivation), Who(People) and How(Function).
Here is an image from Wikipedia:
Here is a helpful hint for row Descriptions ( = means is equal to :-) ):
Scope=Contextual = Planner
Business Model= Conceptual = Owner
System Model = Logical = Designer
Technology Model = Physical = Builder
Detailed Representations = Detailed = Sub Contractor
Zachman framework usage
- Every architectural artifact created in the Enterprise Architecture practice should belong to one and only one cell. So for instance, if we create a Data Architecture it should belong in the System Model(Designer) ==>Data cell.
- Every cell needs to be complete which means we need to have some artifact that applies to that perspective.
- The key thing to remember is that the information in columns should be related to each other or have a strong correspondence with each other. For instance, if we are creating artifacts related to Data then these artifacts should talk about the same data from different perspectives. Let's say data represents Customers for a Business Owner and is represented in the business data model diagram. These same customers should be represented in the Physical(Technology model) data diagram as well and should describe how Customers are actually represented in terms of the technology being used.
So to summarize, Zachman Framework gives us a way to classify architectural artifacts and ensure that all perspectives are met and that they actually address the same problem. It however does not give a step by step process for creating Enterprise architecture. It doesn't say how the artifacts have to be created, what should be in those artifacts and how should they be consumed.
TOGAF®( The Open Group Architecture Framework)
I hear a lot about TOGAF especially from IBM folks. :-) Not sure of the exact reasons but maybe because it's owned by "The Open Group" and also because of heavy SOA practitioners bias.
To Quote the description from Wikipedia:
"The Open Group Architecture Framework (TOGAF®) is a framework for enterprise architecture which provides a comprehensive approach for designing, planning, implementation, and governance of an enterprise information architecture. TOGAF is a registered trademark of The Open Group in the United States and Other countries [2]. TOGAF is a high level and holistic approach to design, which is typically modeled at four levels: Business, Application, Data, and Technology. It tries to give a well-tested overall starting model to information architects, which can then be built upon. It relies heavily on modularization, standardization and already existing, proven technologies and products".
To put it simply, TOGAF is a step by step process for creating an Enterprise Architecture. So if one wanted to combine Zachman and TOGAF, then they could create the artifacts with TOGAF and then categorize them with Zachman.
An explanation of few key terms used in TOGAF:
Enterprise Continuum
TOGAF views the enterprise architecture as a continuum of architectures.
Foundation Architectures
These are generic architectures that can be used by any IT organization.
Common System Architectures
These are principles visible in many but not all enterprises.
Industry Architectures
These are specific across enterprises that belong to the same domain. For instance Healthcare.
Organizational Architectures
These are very specific to a given enterprise.
ADM
At the heart of TOGAF is ADM(Architecture Development Method). ADM describes a method for creating Enterprise Architecture. The basic structure of ADM is shown in an Architectural Development Cycle ( ADC). Here is an image from Wikipedia:
ADM is iterative over the whole process, between phases and within phases as well. ADM has been specifically designed with flexibility and adaptability in mind. The phases in ADC could be adapted and their order changed to suit an organization. Also ADM could be integrated with other frameworks or methodologies such as the Zachman Framework and this might result in a modified ADC.
A brief description of the phases.
Phase A
This will define the scope of the project, identify constraints, document requirements and establish high level definitions for current and target architectures. Output is Statement of architecture work.
Phase B
This could be very time consuming depending on the scope and the depth of the Business Modelling effort. Output will be the current and target business objectives.
Phase C
Again, this is detailed as well and there are multiple steps to be followed here. It basically boils down to developing current data-architecture description, architectural models, logical data models, data-management process models and relationship models that map business models to CRUD.
Phase D
This involves completing the technical architecture i.e. the infrastructure to support the new enterprise.
Phase E and F
Identifies the implementation projects with focus on easy-wins or projects that could have the most visible impact with least risk.
Phase G
Involves creating architectural specifications and acceptance criteria of the implementation projects
Phase H
The final phase involves management of the artifacts created.
..And the cycle could repeat itself....
Federal Enterprise Architecture (FEA)
I am not familiar at all with FEA but the below resource makes me unenthusiastic about FEA.
FEA reference models Tragically Misnamed
However just glancing through it, it seems to have five reference models:
- Business Reference Model ( BRM)
Business view of the various functions of the federal government.
- Components Reference Model (CRM)
IT view of systems
- Technical Reference Model (TRM)
The Technologies and Standards that can be used in building IT systems.
- Data Reference Model ( DRM)
Standard way of describing data.
- Performance Reference Model ( PRM)
Describes the value delivered by EA.
FEA seems to be a very well defined framework but I don't want to explore it at this point. Maybe if something piques my interest.
Gartner
Never had a chance to use this but might be useful in certain contexts. It might be interesting to find out if this applies in non-Garter engagements as well or is only a Gartner specific thing?
Conclusion
Since these frameworks are highly theoretical, verbose and in some cases very confusing, it's best for an organization to pick one or two EA frameworks and combine the best elements from them to create an Enterprise/Industry specific framework. A framework that recognizes the Business, Technology and People constraints of an enterprise and creates a framework that allows EA to be in sync with the Business needs and doesn't overwhelm the process or people(Technologists or Stakeholders) involved.
The key is to remember that not all organizations have well defined processes and not all organizations have mature IT or EA practice. Such organizations need a scaled down version of EA that excites them and provides visibility into the solutions that are being address by EA.
This bring us to the end of the post here and leads to our next main topic around Grid and Cloud Computing etc. This one is almost on everyone's mind and one that comes up so many times in discussions that it's fair to say it's currently the hottest topic.
Resources
Wikipedia
The opinions and statements in this communication are my own and do not necessarily reflect the opinions or policies of CA.
No comments:
Post a Comment