Here is my take on trying to define Enterprise Architecture:
It is a methodology
that provides a process, guidelines and techniques that help in developing an 'Enterprise Landscape' consisting of its Business Processes, its IT applications, its Data and its supporting Infrastructure (including their geographical spread)
thus enabling the enterprise to optimize and manage complexity, respond quickly to changes and align itself to the enterprise's Strategic Goal and Objectives
with clear transitional steps from the current state to the desired state, in the least disruptive way possible.
My thoughts on various things as I explore and learn. If you are an interested android developer, you can visit my android blog
Amazon Ads
Friday, January 21, 2011
TOGAF 9 - A Brief Introduction
In the next few articles, I will be sharing my thoughts on TOGAF 9 as I am discovering it…
TOGAF 9, at the very outset is an Enterprise Architecture Methodology and a Framework. What does it mean? In simple terms, it provides the process to be followed as well as the content taxonomy along with some suggested techniques. It leds itself to tailoring for an enterprise's specific needs.
However, it also seems like a methodology that is very inclined towards the "IT nature" of an enterprise. I will write a separate blog article on why I feel so, with references to the TOGAF methodology.
Through its famous ADM (Architecture Development Method), it tells the various phases of a typical enterprise architecture iteration (as this needs to be done in iterations to be able to cover all the functions / verticals in an enterprise).
I will briefly touch upon the 6 main parts that constitute TOGAF completely:
- The Architecture Development Method (ADM)
- ADM Guidelines and Techniques
- The Enterprise Continuum
- Architecture Content Framework
- TOGAF Reference Models
- The Architecture Capability Framework
A few words about what each of these mean:
ADM – This is a major component of TOGAF and provides guidance to the Enterprise Architecture group on the possible architecture development phases with each phase being described with details such as an objective, approach, inputs, steps, outputs. This is executed iteratively.
ADM Guidelines and Techniques – provides a large number of guidelines and techniques on how to apply ADM. Guidelines help to adapt the ADM. Techniques support specific tasks in ADM.
These I found to be basic, useful starting points and extensible.
The Enterprise Continuum – provides a model for structuring a virtual repository and provides methods for classifying architecture and solution artifacts.
It helps in categorizing based on industry standards, architectural patterns etc. While TOGAF 8 just provided this, TOGAF 9 provides the below mentioned Architecture Content Framework which is one way of realizing the Enterprise Continuum.
Architecture Content Framework – provides a detailed model or meta model of architectural work products including deliverables, artifacts and the Architecture building blocks. This is one realization of the Enterprise Continuum.
This is very useful for creating taxonomy of enterprise architecture artifacts generated throughout the lifecycle of architectural work. Any repository to be maintained in the enterprise can get a starting point here.
The common thread across TOGAF is that every single bit is almost customizable to the context of one’s enterprise.
TOGAF Reference Models – This provides one integration / interoperability reference model called the III-RM (Integrated Information Infrastructure Reference Model) and the TRM (Technical Reference Model).
In my opinion, probably something known well in the industry and probably a bit archaic!
The Architecture Capability Framework – These are certain guidelines and resources to help an architect set up the architecture practice in an organization.
This would be useful especially in the beginning of an EA practice.
Benefits of Enterprise Architecture
Of late, I have been wondering a lot about what tangible benefits would any Enterprise Architecture initiative bring to the Enterprise.
Or put in another way, when would an enterprise be driven to set up an Enterprise Architecture practice?
Or put in another way, when would an enterprise be driven to set up an Enterprise Architecture practice?
Here are a few reasons for starting an EA project.
- Rationalize / consolidate a large number of IT assets (data, application and infrastructure) that seem to have outgrown reasonable manageability (Reduce the complexity of IT Systems)
- Create a road-map on how IT will meet the business strategy in the years to come. ( Through performing a gap analysis after understanding the current and the target architectures)
- To enable an enterprise to be "agile".
- For the IT systems to be able to meet the changing business demands in very short cycles
- To enable an impact on the various layers of the organization (Business process, applications, infrastructure) due to a change in the Business Strategy or vision. Note: this is not easy for a large enterprise
- To bring about Process Optimization which could lead to lot of IT-related optimizations
- To bring about standardization across the organizations various sub-organizations
- To ensure the enterprise is compliant to regulatory requirements in a standard way across the organization
Subscribe to:
Posts (Atom)