EA - Enterprise Architecture in Action

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 8:45 AM | Permalink | Comments (1) | TrackBacks (0)

SOA transformation is all very fine, but does is apply to all situations? For example, how do you apply SOA principles to organizations where the multitude of desktop users love the spreadsheet interface and swear by it? Perhaps a better question is, how should you apply SOA principles to environments where users are not looking to share information between desktops, where the ultimate flexibility of your own personal spreadsheet is inherently the differentiator between your product and your competition's, and where SOA is looked on as "Simply Over Ambitious?"

The finance world lives in spreadsheets. And, to give Microsoft due credit, they have marketed a whiz-bang product with Excel. A large percentage of financial models exist in spreadsheets, and they drive the financial products offered by multinational financial institutions. Sharing of information is primarily a matter of sharing a common repository of large files.

So where is the nail for which we have the SOA hammer? While the complex logic of modeling risk and other aspects of financial products is addressed by Excel, the volume of files is becoming an isurmountable problem. Plus, there is no real security for access. This was not a problem when the entire spreadsheet was handled by a small select team; but that is not applicable anymore. Errors and bugs are very hard to track. And cut and paste errors abound.

I faced this very situation at one of our financial clients. The client originally engaged another consulting firm to provide a solution to these problems. A grand SOA vision was drawn up. After about a year, the client lost patience, and were especially peeved when they saw the first deliverable about 12 months away. So they scaled back and asked for something small. That was when they engaged us.

SOA in the small? It is a kind of paradox. However, the real question to ask is, where is it truly applicable in this scenario? The answer is - "data management." Data from several disparate systems makes its way into the spreadsheets. This data needs to be standardized, cleansed, and integrated through common meshanisms. But wait a minute. Is this not an EAI problem? Where does SOA come in?

The very basic services under the SOA umbrella are foundation services. These basically include data gateways and the like to enable consumption and querying of data. Providing these services as a layer above the native integration with systems like Bloomberg allows the middle tier systems to make them available for consumption by spreadsheets. Once the services are built, they can be shared by trading systems that need the data for transactions.

 This is definitely "SOA in the small." And it doesn't even go into the aspects of organizational governance. Nevertheless, it prepares the framework for departments to participate in the larger SOA initiatives that are already in inception across the whole organization.

Posted by Ajit Sagar at 11:46 PM | Permalink | Comments (5) | TrackBacks (0)

In recent years the BPM space has evolved significantly. During the past 4 years BPM license revenue has grown nearly 100% yoy. As per leading analysts firms, BPM is the next big wave of the IT industry. Currently over 50 vendors claim to offer BPM suite that would transform clients business by making the systems agile. However, the reality is that many enterprises, and even product vendors, are focused mainly only on Business Process Modeling rather than having holistic approach for entire BPM lifecycle.

I think the main reason why process modeling stimulates a lot of excitement, while complete BPM lifecycle gets less emphasis is due to the fact that process models are tangible artifacts that both business and IT can very much relate to and the gains can be quickly realized; while on the other hand, implementing complete BPM solution can be quite overwhelming and the value realization has much longer gestation period.

Process Modeling is definitely a very critical phase of building the BPM solution, however the full value from BPM is realized when the business is able to manage the performance of business processes.

Implementing a BPM solution involves externalization of business process flow logic and frequently changing business rules (such as tax computation, discounting policy, credit approval rules etc) from cryptic computer code into language that business users can understand. This enables business users or semi-technical personnel to quickly change the process flow and business rules to adapt to the changing market needs, making the systems agile.

Another very critical aspect of a BPM solution is Business Activity Monitoring (BAM), which includes systems & infrastructure that enables monitoring and analyzing business performance. This provides critical insights into the real impediments in business performance and providing vital clues for optimizing business processes.

Implementing the complete BPM lifecycle - from process discovery & modeling to business activity monitoring, analysis & optimization – enables the enterprise to continuously optimize their business performance.

Most of the CTOs, Enterprise Architects and IT Managers that I have had the opportunity to collaborate with share the above views. But the real challenge is how a large enterprise should plan their BPM journey that encompasses the complete BPM lifecycle from modeling to monitoring. From my experiences I have learnt following lessons that make implementing the complete BPM lifecycle less intimidating.

1. Don’t try to boil the ocean – start with very few simple but high impact business processes

2. Clearly define business measures and key performance indicators (KPIs), and set realistic improvement targets - Setting business performance improvement targets sets the focus firmly on performance monitoring and optimization (which requires implementing complete BPM lifecycle) rather than only focus on Process modeling & white boarding exercise that very often leads into intellectual deliberations that far from business reality

3. Don’t try to solve the puzzle during process analysis, wait for the real business performance analysis – One of the key value propositions of BPM is that it makes the systems agile and very easy to change. Don’t aim to completely optimize the business processes during process analysis & modeling phase. During this phase just look for the obvious pitfalls and improvement opportunities and move forward. Since BPM systems are very ease to change let the processes evolve and mature through the real process improvement feedbacks that come from business activity monitoring & analysis. I have seen many BPM projects getting caught into the ‘analysis – paralysis syndrome’, leading to enormous delays and budget escalations which most often results in key stakeholders loosing interest and  creating beliefs that BPM is one more big hollow promise of the IT industry.

4. Choosing the right tools & technologies – It’s extremely important to conduct extensive research while choosing the BPM suite. Many of the leading and widely used BPM tools are yet not fully matured on all aspects of BPM lifecycle. In fact only few BPM products have good process monitoring capabilities. Many BPM products leverage other partners’ products to cover some of the BPM lifecycle stages, including even process execution and integration engines. Such hybrid BPM suites have serious limitations in interoperability and roundtrip even between the tools within the suite. Also many of the BPM products are built on proprietary standards severely limiting the interoperability with other reporting & analysis tools and other IT systems within the enterprise. Thus selecting right BPM suite is very critical for implementing enterprise wide BPM solution that encompasses complete BPM lifecycle

5. Establish BPM governance and process owners’ office at very early stage – Many of the large BPM initiatives involve processes that are cross departmental / business functions. Implementing process management solution for such processes requires clarity on ownership. Establishing BPM governance, especially process owners, is very critical in successfully implementing and managing cross departmental processes

6. Collective ownership of Business & IT – In most organizations the BPM projects are initiated and owned solely by IT, with very little participation from business. From my experience I have learnt that if IT owns BPM projects they are often heavily focused on ‘best architecture’ and system performance (e.g. trying to reduce function latency time from 0.8 seconds to 0.2 seconds), rather than focus on building system that enables continuous improvement in business performance. Similarly, the BPM projects that are completely owned by business often tend to focus too much on improving at very early stage the business processes and user interfaces and interaction patterns, losing sight on the real goal of putting in place the infrastructure that enables continuous feedback loop for business performance improvement. It’s imortant that BPM initiatives are jointly owned by business & IT. Establishing clearly defined BPM Governance framework ensures clarity of roles & responsibilities of all stakeholders

Posted by Dhiren Mehta at 4:07 AM | Permalink | Comments (1) | TrackBacks (0)

In many enterprise IT organizations, there are separate teams those are focused on Enterprise Architecture (EA) vs. Service Oriented Architecture (SOA). So many IT executives wonder the need of two separate entities. The usual questions are 1) does one replaces the other or are they complementary? 2) are there overlaps? 3) how to decide the boundary of responsibilities?

During a recent discussion, to answer these questions I used a parallel from my daughter’s toy room. I explained ‘EA is like a Jigsaw puzzle and SOA is like LEGO builds’.

As per Wikipedia, a jigsaw puzzle is a tiling puzzle that requires the assembly of numerous small, often oddly shaped, interlocking and tessellating pieces. Each piece has a small part of a picture on it; when complete, a jigsaw puzzle produces a complete picture. Here the complete picture is the Enterprise Architecture. Each tile defines the technologies with products and packaging of it. EA brings the oddly shaped technologies together to interlock and complete the tessellation. In essence, it is often two dimensional.

SOA brings the three dimensional picture where the organizational can build new composites (the LEGO builds) using the services (bricks). The builds are often multi-level, hierarchical and extensible. 

Finally one person from the group asked- so what is Governance in Jigsaw or LEGO? The answer came from the group “it is that writings/instructions on the outside of the box or inside the instruction manual”. Looks like my analogy worked.

But, in LEGO, the governance is just guided by LEGO tubes. As per LEGO “The interlocking principle with its tubes makes it unique, and offers unlimited building possibilities. It's just a matter of getting the imagination going – and letting a wealth of creative ideas emerge through play”.

Now I am wondering whether we can have such similar simple, but powerful governance for SOA? May be yes. Lets our imagination work.  

To play LEGO online, please visit LEGO Factory  http://factory.lego.com/getstarted/default.aspx. You can conduct ‘PoCs’ and there are many “reference implementations” too.

 

 

Posted by Binooj Purayath at 6:02 PM | 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 6: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 5: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 1:58 PM | Permalink | Comments (2) | TrackBacks (0)