We will go across the varying horizontal layers in a vertical fashion creating models or adding notes and analyzing the various components in order to achieve our target state. The nature or outcome of this process from moving the system towards the evolving to be state or Read the rest…

For the purposes of this course please note that the terms of process methodology and approach can be used interchangeably. The very basic architecture process or method in which architecture is constructed is to review gather or create a current architecture otherwise known as a baseline Read the rest…

I am continually faced with the same question from my clients who are contemplating the EA journey. They want to know how to justify the investment and time, and can’t seem to get the Executives to get past the mere suggestion of the topic. In the past, I attended two interesting sessions on Disaster Recovery Planning and a status check on Sarbanes Oxley.

As usual, both brought me back to thoughts pertaining to EA. I am still amazed by those who will fork out the mega bucks to pay for a one or two year project on DR, but won’t let any conversations roll on EA. My suggestion have always been that if we had EA, we would spend a mere fraction of the time on DR. Most DR’s fail because they focus on planning out EVERYTHING instead of what is important. They are too granular too early, and would be much more successful if they included some good scope planning.

Now many of you are still wondering what this has to do with power, and inventory. A few years back I did some work on an Enterprise Architecture Plan for a large organization. They hired me to review their framework and their ERP to date. When I asked where the current state section was, they said “Oh, we don’t want to spend money on that – we know what we have – the value is in the target”.

Don’t worry – I’m not going to get into a huge lecture on EA strategy, nor on the whole EA Process. This comment is more common than you think. Do you know how many IT organizations think they know what they have, when they really “roughly know” what they have. When it comes time to make any serious decisions, do they really know how many servers have how many and which applications running on them with which databases for which business processes? I doubt it.

Any if they did roughly know, why do you think almost every technical or application project starts out with the same analysis? “Well, we’ll just send someone out to find out which databases run on that server before we upgrade it.” Another comment might be – “well, we need to change that business rule – can you find out which parts of the application are affected”, or “which systems are affected by this legislation change?”

This is so common and the amount of work incurred to answer these questions over and over again is never accounted for. It is sucked up into the project in question, and little thought is ever given to the value of the Enterprise Architecture. Many will acknowledge that if they had it, some of these questions would be easier, but we haven’t put a specific value or cost of not doing it together, making it forever impossible to get it approved!

My comment for today is this – the power is in inventory. Current state is in part just that – taking into account what you have and how it is related. My comment earlier regarding the organization that didn’t want to spend time on current state because they didn’t have the time to go out and inventory all of their departments. Guess what?

They still don’t have an actionable EAP, and as far as I know, their EA Project has stalled. You can’t really figure out where you are going unless you know where you have been, and if you can’t budget for an EA Program, a good start might be creating small, incremental inventories each time you have a large project, slowly whittling away at the problem.