All the time I get the questions about how to do current state architecture or “as-is” architecture at executive briefings (EBC), at events or through our customers. Recently I was asked about this in regards to an effort a large enterprise that is undergoing an effort to map out what their current architecture. As with many companies large and small, there is a reconciliation of IT assets that are being being collected and hopefully distilled into something meaningful to make decisions off of. This is compounded by the economy that has a tone of “doing more with less” and IT optimization.
With the question of current state architecture, it is both a deep and vast area to cover. As you can see from my choice of the image above (depiction of Christopher Columbus claiming the New World) this is a substantial space to cover.
The reason I say this is that it isn’t as simple as understanding a modeling language or notation and then run out and document your enterprise. Outside of the tooling, architecture standards and technology you must understand some outside forces when performing a current state analysis. Below are a sample (not in order) of aspect you must understand:
Deep understanding of the CEO & CIO mission and objectives
Deep understanding of mission critical solution areas
Deep understanding of the enterprise
Deep and vast understanding of the business
Vast understanding of your IT landscape
Vast understanding of your industry
You maybe wondering, I am an architect why should I care about these? Simply put, you must care because you will have to figure out where to start from. Do you start at the CRM system? How about the mission critical Online Banking System? Or maybe start simple with the FoxPro database applications in a LOB somewhere.
If you are not careful you can get a derive to a current state that is neither understandable or usable as seen from the popular example below:
Having context and purpose before walking into an very nebulous architecture effort such as this very important to your overall success. Metrics being the driver of success here. If you are able to qualify the effort you can get some measures of success out of your effort.
So to be effective at you current state analysis we must tie into the organization priorities through a repeatable framework. This corresponds with a repeatable current state process or methodology that is derived from the mission and strategies of the company all up. A model like shown below.
I often hear of horror stories of companies doing a massive current state analysis that turns into a multi-year project and yielding minimal results. The key here is to be strategic about your current state architecture efforts. The issue is that it is easy to “rat hole” into the classic problem of analysis paralysis.
This is an iterative process of focusing on assets that are the highest to lowest priority. Since the future state of any company and subsequently the IT environment is always in motion, we must be mindful of that this movement will occur and build that movement into our plans. The most effective way to deal with this is to create an iterative process like the one below to effectively perform a current state analysis.
As you can see we are bridging the CEO/IT strategies into account and letting that drive the current state analysis. Effectively we want to focus on the top priorities of the company first and then iterate the process for the next tier of priorities.This solves the problem of the is that the enterprise loosing focus on the assets they should be identifying at the right time.
An example of segmenting tiers is shown below.
Each enterprise will have a slightly different way of looking at this but the process should be similar. The tiers will also be implemented in waves. Meaning that you should perform a current state analysis in digestible chucks. I wouldn’t do more than 10 systems at any one time. This keeps a level of focus and increases the overall success of the effort. The only exception here is that as you move down the tiers you can get away with looking at more solutions at a given wave.
Obviously, when we look at implementing this model there is a great amount of detail that needs to be covered in the people, process and tools but this will give us a common way of thinking about the problem.
Without getting too much into process I will focus on where the industry is at with useful standards or tools that will help execute on a current state analysis. With that lets look at defining architectural models and how to build them.
To determine what a architectural model is or sometimes even just as important what an architecture model is not we need to start with a fundamental architecture taxonomy and ontology. Both of these terms are broad and have deep implications but if we keep it simple and say that an ontology that defines a consistent set of definitions on assets, concepts, abstraction and classifications. Then having a taxonomy will show how these pieces fit together in the context of architectural descriptions. This will help qualify the architectural models in the enterprise.
A good starter resource would be to look at IEEE 1471. I wrote a post about this (Making Sense of Architecture Standards) describing what IEEE 1471 is all about an how it contrasts with other standards. There is also a good article from the Open Group entitled Impact Assessment of IEEE 1471 on TOGAF that contrasts IEEE 1471 with their EA framework.
For more information on IEEE 1471 go to their web site at: http://www.iso-architecture.org/ieee-1471/index.html
There has also been some recent developments in this area as from the framework community.
TOGAF 9 has released the start of what looks to be promising in two areas. If this continues to grow from the user community I think it could be very compelling.
Taxonomy and Ontology / Metamodel - I reference this in my post TOGAF 9 Release and Impressions where I talk about their metamodels and repository efforts. TOGAF is making strides in this area. Granted there still needs to be more work but it looks as if they are heading in the right direction. What’s positive about this even though it isn’t complete is that there is a ground swelling of support and community that is vested in this. Unlike other architectural standards, this one has a significant community that can help drive the standards forward. The side effect of this is that it becomes the defacto standard based on the shier amount of architects in that community thus having a level of uniformity in the industry when thinking about architectural information models.
Modeling and Notation – Now that Archimate is part of TOGAF there is now cohesion between the metamodel and the actual model with an architecture markup description language (ADML) and modeling notations.
Even though frameworks provide a lot of value be careful not to loose sight of the objectives. It is easy to do. Also, you may want to borrow from multiple frameworks as there are aspects of each that are unique in it’s own way. For example, Zachman provides a great way to group and classify information but you could use another framework like TOGAF to introduce decision making process to that, likewise with all the other frameworks.
All in all, a very exciting time for architects. There is a lot of new developments and opportunity to further the industry.
Other related posts that I have made externally on my blog that may help you out are listed below as well:
There is also a Enterprise Architecture Toolkit that was developed that aid with some aspects of this:
Commenti