Posted by Markus:
When we talk about Enterprise Architecture, we typically talk and refer to the four classic TOGAF dimensions and how they need to be aligned:
- Technology
- Business
- Information
- Application
One thing we often do not talk about is Time.
Is this because we take for granted that we all understand the importance of the time dimension in our Enterprise Architecture Planning Process?
I am not so sure.
I have worked with a number of organizations in the past that claim to have developed and implemented home grown systems to manage and govern their most important EA assets like applications, components, deployments, even business processes.
What I heard very rarely is that those repositories actually embedded the radical concept of time in their data model.
All of those EA assets and artifacts actually have a life cycle , don’t they?
Technologies come and go.
Applications are deployed and phased out.
Business processes are introduced and are changed.
Let’s look at an example on the Technology Level:
Microsoft updates its Internet Explorer product in frequent release cycles. IE 5.0, IE 6.0, IE 7.0 or the current version IE 8.0 are all familiar to us. So Internet Explorer as an IT asset has multiple versions, each version has a life cycle that is defined by the vendor.
General Availability will be on a specific date, the product is supported for X years, after which it can go into extended support (typically much more expensive than standard support) before it will be end-of-life’d.
Then there is the internal Enterprise support life cycle for Internet Explorer.
When does your company plan to bring the new release in-house and actually start using it in production?
When will you stop using a specific release? When will Desktops / Workstations be updated with the new release?
Most companies bring products in-house and the product will go through internal stages like pilot phase, production phase, phase-out and retired. This overall internal Enterprise lifecycle defines the time period when a specific Internet Explorer release is considered a “standard” and is internally supported by the IT organization.
But we are not done yet:
When we deploy application internally, do we always roll them out to all parts of the business at the same time?
No, not always. I might roll out SAP FI in Europe in 2010 but start deployment in Latin America in 2012 .
So applications can have additional (in this example regional) life cycles that need to be considered, kind of a business support life cycle.
And because Internet Explorer is the UI component of our internal web-based applications, each application version defines which version of IE it supports or requires. So it is critical to synchronize the application life cycle with the life-cycles of the technical components. Think about the life-cycle dependencies between an enterprise application and it’s underling components like Operating System, Database System, UI component, web server, application server, etc etc and it is clear that this is a challenging synchronization task.
I think you start to understand that managing the life-cycles of artifacts and the dependency between the life-cycles is absolutely critical in the EA world.
Compare this to the notion of real Supply Chain Planning in an manufacturing enterprise.
It is not enough to know what is currently in stock. ERP Supply Chain Planning takes into consideration what was in stock (to derive trends and forecasts) and what will be in stock in the future based on incoming demand, scheduled production or other supply chain planning events. In ERP inventory terms, this is often referred to as “Available to Promise” describing the future state of my supply chain inventory. Forward looking inventory and supply chain levels are basic building blocks of a real-world supply chain planning system.
Especially from a forward looking EA planning perspective, it is simply not enough to capture the current status quo of your application inventory.
To be able to do true Enterprise Architecture Planning, EA artifacts and their respective time lines and life cycles need to be considered and managed as part of the system of record.
And there are many of them that have time lines:
- applications
- components
- business supports (when is a specific application used in a specific organization)
- Interfaces
- deployments
This is why every Enterprise Architecture Program needs an artifact repository that knows and manages the dimension of time.
In evaluating EA solutions, pay specific attention to this.
Comments are welcome!
photo credit: Lainey
Recent Comments