EA - Enterprise Architecture or Extreme Aggravation

Writing this - I just returned from the Middle East. We are working on defining the securities processing landscape of a major investment bank in the region. This process and IT landscape is supposed to be a major enabler for growth. How does this impact the competitive landscape? Is such an investment strategic?

Banking in the Middle East is growing like nothing (well, all those petrodollars need to go somewhere ). There are also strong regulatory drivers transforming the landscape. And the clear will of the governments is to diversify their economies away from oil, among others into Financial Services.

These financial institutions will not have to fight legacy applications. Launching new products will be quicker, as it does not require changes in code dating back to 1974 (as in a European bank I once worked for), and a proper segmentation of the landscape will contain change to a minimum.

But system landscape is only a small part of the new enterprise architecture. Enterprise architecture is about the way an entity organizes and reconfigures its resources to achieve its objectives. It includes value chains and support processes - Because a new product not only requires a trading platform – but also needs people trained to handle them, and marketing to let the world know about it.

Integrating all this provides strategic capabilities to the bank – underpinning the organization’s value proposition. This will give the banks of the region - and in a similar way those of many emerging economies - a competitive edge against established institutions.

Posted by Thomas Obitz at 08:45 AM | Permalink | Comments (1) | TrackBacks (0)

- Sohrab Kakalia 

Reviewing sales or RFPs is not always the only way to check the pulse of the market. A subtle way to check the trends in the market is to look at the employment opportunities or jobs on offer in the market. In recent months there is a growing demand for hiring enterprise architects in many Fortune 500 companies. These firms are specifically looking for capability in assessing and driving large IT transformation or modernization across multiple applications.

The drivers for this are the obvious

1. growing consumer demand for online and consequently, the near real-time services that need to be provided
2. cost optimization across systems built over the years and the demand to track ROI, 
3. build systems that are inter-operable and flexible in line with SOA and EDA architectures and finally
4. better data quality and Master Data Management across customers, products and operations which in turn build good business intelligence and reporting capability.
   

As the need for architecture is growing, we might see some interesting consolidation among the vendors whose tools form a baseline and reference for such large programs. IBMs acquisition of Rational was only the beginning, followed by Telelogic acquiring Popkin in 2005 and IBM acquiring Telelogic. We will see some more coming soon as conventional strategy or infrastructure players enter the application transformation space.

Posted by Guest Author at 06:30 AM | Permalink | Comments (5) | TrackBacks (0)

As well as an increase in the number of Enterprise Architects, there’s also an increase in the number of people asking “how do I quantify the value of Enterprise Architecture (EA) to my organisation?” or “what value does my EA group provide?”

There was a time when people would nod when the benefits of EA were mentioned:
better integration from all perspectives (lots of nodding); improved ‘alignment’ between ‘business’ needs and IT spend (vigorous nodding); reduced IT TCO (big smiles); manage change more effectively (looking round the room to see who else is nodding); better support for risk reduction & compliance (jaws tightening); basis for continual improvement and KM (some raised eyebrows)….. Increasingly, the nodding is followed by a “well, prove it” or a “well, I don’t see my EA group providing those benefits” (not good for the EA group!).

Most of the things that need to be done seem obvious (but aren’t always done for various reasons): identifying ‘customers’ and stakeholders for EA ‘services’ ; understanding priorities and needs; agreeing on the basis for architectural maturity assessments to get involvement as well as a basis for planning and showing progress, communication plans (including benefit demonstration)…

Another key element in the ‘value arena’ is ensuring that the processes that approve projects and measure benefit are set up to support recognition of EA benefits. Some organisations ‘buy into’ EA in theory but only look at the cost/benefit of individual ‘projects’ and do not explicitly have somewhere that EA benefits can be recognised (gets a bit easier with programs compared with projects).  

Although the context is changing in some ways, it’s worth having a look behind Zachman’s quote “You can’t cost justify architecture”.

There’s not a huge amount of publicly available, systematic information on actual benefits from EA programs and functions. However, a couple of places worth a skim:
•    Gartner’s “Applying Enterprise Architecture” which gives a couple of examples (NB: subscription required)  
•    Survey of over 250 CIOs last year about architecture - exec summary:  
•    Some great images and breakdowns on the “Institute of Software Architects” page:

On a lighter note, there’s a great cartoon at ‘Geek and Poke' with a ‘techie’ talking to a ‘budget holder’: (I changed it very slightly):

Techie: “…WOA, SOA, TOGAF...”
Budget Holder: “ROI?”
Techie: “don’t bother me with buzzwords!”

(not really the same without the cartoon, see it here - sadly it happens too often).

Cheers
Andrew

Posted by Andrew Manning at 05:01 AM | Permalink | Comments (1) | TrackBacks (0)

- Sanda Morar 

In my previous post, I was talking about my presentation on TOGAF at The Open Group's conference in Glasgow. Continuing from where I left off...

In the course of the presentation, I covered

What TOGAF is? What TOGAF is not?
In the talk, I showed a magic table with some (debatable) "TOGAF is" and "TOGAF is not" points. For example, TOGAF is generic, but it is not prescriptive. TOGAF is process driven, but is not artefact driven.

TOGAF gives you some generic artefacts. But it is up to you to gather and decide which artefacts you need. How do you decide "what you need"? How do you know that "what you need" is "what it takes"?

One school of thought is that these decisions are very much influenced by your interpretation of the scope of work and interpretation of the TOGAF framework. Sort of a give and take attitude.

TOGAF is a set of conceptual tools, but it is not a tool. I leave it up to you to identify the "set of conceptual tools". But, let’s be clear here - you will need a tool to implement TOGAF. And yes, if everything else fails, you can use a text editor as your implementation tool.
 
TOGAF is "flexible", but it is not "ontology driven". Again, this is something I leave up to you to figure out.

I find that all the "TOGAF is not" mentions above (and there were more in the presentation) make TOGAF very beautiful and give a lot of freedom. You can invent (not reinvent the wheel), you can create, you can reuse. Every time you have a choice to embark on a different journey through TOGAF. There are really no limits in customising, modelling and extending TOGAF. And that approach means that you can apply TOGAF beyond known limits, and yes, get the expected benefits and results beyond the limits too..

In that context, you may want to check out the examples shown in the presentation about how to enlist support, how to customise ADM, what ADMN is and is not, how to create a meta model and what to do next.

Apart from the great sessions I attended at the conference, I also discovered some gems. As I am running late, I will only mention two of them to you:

•    BIiZZ Design pocket Guide Enterprise Architecture - smashing life saving book
•    ABACUS tool - I found this tool very simple to use and extremely useful in making the Architecture predictable

Posted by Guest Author at 01:58 PM | Permalink | Comments (2) | TrackBacks (0)