Enterprise Architecture Approaches

I am curious to hear about various Metastorm customer approaches to EA.

In the past few years I have seen several 'bottom-up' approaches that are IT driven. In recent years I am starting to see a more strategy driven EA where organizations are aligning their IT investments with their business strategy.

What are some of the challenges that you face in your current EA program?

Thanks

Gerry

Find more posts tagged with

BPM

Comments

John Grygorcewicz

Gerry,

I think that the fact that you did not get any responses may indicate either that no one is doing much with EA or are having no problems.

My issue with the current approaches to EA is that they are still very focused on the IT pillar and not much on the business side. This could be because EA is being pushed by IT centric organizations. Even though they all start out talking about all of the pillars they very quickly move to an IT only focus.

Don't get me wrong, I think It is important, but it should not deminish the need to maintain focus on the business side. For each IT initiative that comes from an EA approach, it would be interesting to see how many of them have had a post deployment review of if the business case that was used to generate the IT initiative was actually met. I have seen a lot of effort on the initial business case to justify an IT project, and the relevant spend on software and hardware, under an EA banner but not many reviews on the actual results. What I have seen are only the positive ones, nothing on the failures and by the law of averages there must have been a few.

Regards

John

jim clendon

Hi Gery

We have an enterprise architecture which was driven for anumber of years from a technology and system point of view. In the last 12 months have focused on connecting what was largely technology and system architecture to the business architecture.

In doing this we have recognised the value in following the money. For each system or technology area we find the operating costs are a small fraction of the related process costs. By looking at where we are investing our capital we were able to determine that this didn't have the correlation to our strategy we expected. We have created a framework based on industry standards for what we do (Telecommunicationms), and have used that to link to our products, processes, systems, technology, organisation etc. This approach has been one of picking an area where we needed answers and doing the work to get those answers. The challenge has been how to make sure how you model to naswer one question doesn't make answering the next question harder.

We are now including benefits realization management into the mix to ensure that we realise the appropiate benefit from our investment.

We have built a custom modelling language from core which combines BPMN and Enteprise Architecture. We have very few custom objects but introducted a custom object called "Product" which we are using to track the processes and systems that produce and deliver products to our customers (or product components, or resources to malk the components). Another is the "legend" object which we use simply to creatre colour keys for use in models. We use stereotype extensively to model different concepts with the objects available to us. We have some custom links like "supplierlink", "productproduction", "supersedelink" (where one system / technology / activity will superceed another), "aliaslink" (where was have an record with a different name for say a system, an alternatrive name) We have documented much of this in a reference notebook.

We were going to present at this years Metastorm conference but were not able to get approval to travel (we are in New Zealand).

Happy top dicusss if you want to contact me.

Anton Venter

In response to Gerry's EA comment :-

Our org started with a project doing process modelling and needing a tool - that's how Provision was brought in and started being used "top-down".

I am in Architecture and have started using Provision for "bottom-up" modelling, but realised we have to end up with a common repository across the org.

Now working with the BPM project to agree a common Metamodel so the two ends will meet (something like an hourglass......large at top and bottom, but sand will flow in between!).

Answer is to have a central COE to manage all of this..........