An IBM view on EA

The following is based on my analysis of:
- http://www.it-director.com/technology/sys_mgmt/content.php?cid=11379&page=1
- http://download.boulder.ibm.com/ibmdl/pub/software/dw/wes/bpmjournal/0812_jensen/SOA_BPM_EA.pdf

The following is what I understand IBM's position to be. Comments in square brackets [] are mine (not IBM's). It is amazing when one looks at IBM's position one can only conclude that the tooling they offer is unsuited to the purpose.

EA models defines a context in which may be elaborated in more detailed models e g. ER Diagramming, UML, BP Modeller etc. EA needs to understand processes [and presumably rules/policies, information, services, etc.] irrespective of how they are implemented (by what, who, where and how). EA information needs to be able to used to lead to technology implementations. In the integrated scenario Architecture Plans (in EA) are handed downstream, either between companies in the supply chain or within a single entity, to the Build team that continues putting meat on the bones with eye towards product development" [and presumably we must allow that these implementation will be done in technologies from a variety of vendors i.e. so we will need a open way of transition for EA to technology specific tools].

• EA is about "Architecture for Planning"
• EA provides the ability to clearly communication strategies and objectives to the entire organization; and records how technology assets are used to run an enterprise.
• EA's real value comes with the ability to investigate multiple future architecture scenarios and understanding the impacts to assets, organization and process before making the changes.
[so an ability to deal with Iniatives, Scenarios and multiple possible futures is key].
• Enterprise Architect deals in abstractions and things that are always changing, use a generalised tool and are comfortable with "knowing something about everything" vs. Solution Architects (designers) who deal in specialist areas (BPM, SOA etc.) and use specialised tools oriented at engineering design (UML modellers, ER modeller, etc.) and are only happy when knowing "everything about something".
• EA is about "doing the right things", BPM is about "doing things right".

EA, SOA, BPM and are all of value, using all three together can produce the most value. To succeed in you must
• 1st and foremost: establish a collaborative platform supporting the critical dynamic interaction across the enterprise. [presumably this requires many different ways of communication to many in the enterprise]
• have a holistic approach shared by all involved roles, tailored to the culture and environment
• establish awareness amongst key stakeholders across the organization, and particularly look at how to engage the with the business people [which typically not mean forcing them to at technical oriented abstractions of complex models. Rather they will want interfaces, views, reports and visualisations that address their issues and interests]
• think through the lifecycle and how to execute your architectural framework
• be specific about your objectives and have an explicit and accepted governance model, recognise this will often require significant cultural shifts to ensure buy-in to a shared effective process of decision making [so focusing on decision making early would make sense e.g. what questions to be answered]
• enable collaboration through good communication and a sharing of work products, based on a common language, with an understanding of and empathy for roles other than your own
[create artefacts,interfaces, views, reports and visualisations suited to the audience]
• enable integration between enterprise planning and solution delivery across all planes of architecture [using open standards to avoid lock-ins and ensure transparency]

IBM now has one real EA modelling tools - System Architect. Rhapsody is about "Architecture for Building" and is about model-based systems and software design and development. [There are many other tools in with more detailed orientations (SPARX) and one should not see these as EA tools]

On EA in Government - also see:
http://www.govtech.com/gt/articles/698252?id=698252&full=1&story_pg=2

CIOs perform a balancing act between the need for new technology versus the need to contain costs, security versus collaborative processes and accessible data versus the need for business with IT strategies. To achieve this they must close the gap between business and IT by becoming a business executive first and a technologist second. They need to build a hybrid skill set that enables IT professionals to understand the business's needs [and one would have thought communicating effectively with the business i.e. not using abstract technical languages and frameworks].

EA addresses this balancing of business and IT strategies when properly implemented:
- achieve stronger alignment between IT strategy and business goals;
- align various platforms and technologies that have resulted in excessive complexity and cost;
- implement IT standards and governance that enable greater technology efficiencies;
- improve performance, availability, scalability and management of existing architectures and applications;
- support new business processes with new technologies; and
- adopt reusable assets to drive greater efficiencies and faster time to market.

What is the cost maintaining the data we need for informed decision making

I am often asked about the costs of maintain the information needed to make informed decisions.

I have recently got some facts from two different sources - one a bank in Australia and the second a large utility in Europe. Both are of similiar size.

It is difficult to get validated real world data on the broad range of information required (from business strategies, through business operations, through to technology). It may be that some things e.g. business goals and strategies may very little effort to maintain, however things have more properties, characteristics or relationships and may take more effort. Of course with many we can record them at different levels of detail from different perspectives (determined by the focus of our interest.)

Applications are potentially one of the more complicated things that data is captured about. Applications, or more accurately the services and user interfaces that applications provide, are also useful to consider as they are of interest to several parties e.g. business (whose function it is to achieve business results with the services and user interfaces) and technology (whose function it is to provide the services and user interfaces).

The two organisations both capture a few dozen key properties and relationships about they applications and both have similiar intended uses.

One of the organisations uses a strategic IT planning solutions that acts a single of truth for a wide range of business and technical stakeholders. They have calculated that maintaining a set of information they need about applications takes about 90minutes a year.

The other organisation has calculated the manual cost of creating an application inventory costs them 1-2 hours each application, each time it is done (in documents e.g. Word, Excel and Powerpoint). They also say that it is done many times a year to support to many initiatives and assessments (risk, regulatory, cost etc.) and by different parties. If we said that such an inventory is created just 3-4 times a year that would put the cost at 6-8 hours per year.

This reinforces my view that maintaining an enterprise architecture using the right class of solutions has a negative cost i.e. 1.5 hours per year, vs 6-8 hours per year in the case of the applications inventory.

Of course another strategy could be not to gather the information necessary for informed decision making - but few people openly advocate this.

The also ignores the fact that when this information is done in documents it is difficult or impossible to relate to other data, to analyse, to render in different visualisations.

When individualism becomes solipsism

I have just listened for umpteenth time a person say that the way they current deal with the information (in some ratty little document or model that sits in isolation from other scrap of knowledge about the enterprise) suits them well.

Of course it suits them quite well

They created the document for a purpose. If it. If it didn't suit even them, for that purpose - that would really sad. The fact that it doesn't suit anyone else or any other purpose (in fact is probably to most other people most of the time) doesn't seem to have dawned on them.

It is unclear to me if they are unaware that other people exist, or if the idea that some of the knowledge in their documents could in fact be of use to someone else hasn't occurred to them.

What disturbs me most is that of these people claim to be "information" technology "professionals". So if they don't understand the need to manage information effectively what chance have we with others.

I hear:

• IT people say it about their: interfaces, applications, servers, data etc.
• Business people say it about their: capabilities, functions, policies
• Strategists and planners say it about their: plans

Yes - they all realise that no one can answer a simple questions like: what projects affect this interface.

Changing the ways people manage and communicate

Fortunately in my calmer moments I recall the challenges I enountered in the past when trying to introduce new technologies e.g.
- email & word processing - I heard the same things in the 1970s
- computer mapping and CAD systems - I heard the same things in the 1980s
- IM and document management (Cf. Sharepoint, Wiki, Blogs etc.) - I heard the same thing in the 1990s
And now I hear it again.

Michael

Challenges to objectivity (getting typing pool to like email)

I recall many years ago advocating the introduction of word processors and email in place of the old typing pool and mail delivery trolleys. Unsurprisingly a range of people were not too impressed e.g. those who:

• sold contract typists or did typing as a service or
• provided contractors/staff to push around the mail delivery trolleys (or the mail trolleys themselves or the typewriters)
• the typing pool itself (usually an internal function) wasn't pleased.
• the senior executives saw little benefit because they could justify having someone type their

letter and read their mail (and many middle managers aspired to be senior managers so by aspirational affinity - said they could see no benefit).

Many of these people genuinely, and understandably, struggled to be objective. Every conceivable excuse was postulated. As there was practical differentiation in many of the products and services (contract typists, type writers etc.) the vendors of these things were often successful due to the strength of their relationship with senior management. So their interests combined the disinterest of senior management presented powerful opposition.

Fortunately the CFO usually saw the benefit. Sadly the profileration of these document creation tools didn't do much to keep down paper consumption.

I see similar occurring now with the introduction of solutions that seek to provide true enterprise solutions to strategic IT planning, governance, architecture etc. Like email and word processing these systems involve a form disintermediation and democritisation i.e. the people who know record things (not have it recorded for them), and communication is by the people for the people.

These systems are often described as BI for IT, or ERP for IT. Fortunately the implementation of this next generation of tools should eliminate the need for many documents (and emails) and go some way to reduce the amount of paper that needs to be consumed.

Unsurprisingly some people are not too impressed e.g. getting "traditional" strategy, architecture consultants or teams interested in these solution is like trying to get the head of the typing pool (or the person who sells typists) to buy into word processors and email. Ironically the reason many of these people got into strategy and architecture was not to produce artefacts per se - but rather to think, to imagine, to synthesise, to concieve and these solutions would actually free from the drudgery of data collection and collation.

Many consultants working in this area are sadly conflicted and struggle to objectively see that while their self-interest is threatened the paradigm shift is essential.

EA covers a multitude of sins

I am often asked to suggest the best approach (or solutions) for implementing enterprise architecture. The challenge with this is that people mean so many different things by it that it is hard to know what to suggest e.g.

Strategists - usually seek a strategic IT planning solution - they seek solutions that can engage with all constituencies and are focused on establishing a single source of truth. They seek the ability to integrate data from many sources (people and systems) and communicate with many people (visualisations, reports, models etc.). The challenge with this approach is that it can take a long time for the value of the knowledge base created to be visible.

Business oriented architects - usually seek solutions that manage the technology assets (costs, value, risk etc.) and enable a wide group of people to objectively participate in the management of the existing portfolios (services, applications, infrastructure, skills) and plan future investment. The risk with these approaches is undertaking each optimization activity as a stand alone or point in time exercise rather than establishing a systemic solution.

Governance oriented architects - usually seek solutions oriented at compliance with internal and external standards. They also realise that there are many roles and constituencies that need to be engaged (so technical and some not - in any area being considered). They many focus on the management of technical standards, preferred products, patterns etc. A key to the success is that the touch point processes are adapted so that governance is built into them, and feedback loops occur naturally i.e. that the approach is inclusive. The risk with this approach if it is implemented by itself is that it is seen just as barrier to change and initiative.

Framework oriented architects - seek solutions that implement the framework they have educated in or sold on. If the frameworks is oriented around investment planning and business cases based they seek business analysis and business case management for the enterprise (usually portal oriented interfaces with document production); if it is oriented around a set of reference models they seek support for the reference models and the ability to align their enterprise with the reference models; if it is oriented around a taxonomy they seek a predefined set of semantics and views; if it is oriented around a method (a set of steps) they seek a model or portal solution that steps them through the steps with wizard-like simplicity. The risk is that framework zealots focus on the frameworks for their own sake and don’t ground their efforts in terms of visible business value.

Aspect oriented architects - these people are focus on one aspect e.g. data oriented; service oriented; process oriented; object oriented; package oriented etc. and tend to see the needs as extensions to these domain e.g. oriented at data modelling; SOA; process modelling; UML modelling; modelling the capabilities of their preferred package (ERP, CRM etc.), etc.

Solutions oriented architects - often seek extended solutions architecture - what they seek are usually modelling tools for a group of architects to use to communicate principally amongst themselves - with some views created for other constituencies. They will often seek solution of engineering oriented languages and views. Experience shows that these modelling oriented approaches seldom produce sustainable value.

Value or mission oriented architects - are usually driven directly by a project or business imperatives e.g. reduce the cost of X by ...; reduce the time it takes us to do Y by ...; reduce the risks of Z by... . They probably have the best chance of concrete success as they by definition have SMART goals.

When pressed many will say they want all these things - but the solutions they select and how they go about the implementation reflect one or more these orientations. The emphasis on tools depending on how much people place weight on:
- establishing a sustainable enterprise assets (vs meetings the needs of single constituency) which involves strategies for ensuing data consistency, quality
- communicating with all key stakeholders e.g. engaging with them interactively and allow them to enquire
- integrating data from many sources (which requires support for semantics and integration mechanisms)
- modelling and presenting the various views and diagrams that have been produced (often manually) in the past.

Justifying the cost of solutions for strategic IT planning

There are 4 common ways that investments decisions are made.

1/ Common sense e.g. this is how we justify the use of: Office, Email, Accounting systems etc. no one in their right mind would not use them. And this is in fact probably the soundest way to justify them i.e. connecting to specific ROI, or short term business outcomes is problematic and not that sensible i.e. perhaps the benefits are pervasive and manifold.
2/ Associate the business value to some current initiatives e.g. we want to save $X in IT cost/risk and to that we need to do by: doing some things (run some programmes); having some people (staff, consultants etc.) and using some suitable tooling.
3/ Try and create specific metrics that allow an ROI to calculated. The real challenge is usually that the quality of the current state analysis is so poor, that accurately slicing and dicing the costs is challenging (hence the reason for a better approach). And IT is good at burying the dead and excusing under delivery i.e. within 20% of budget, within 50% of time, and achieving 50% of original scope is regarded as a success.
4/ We have people who do this job - they need solutions that enable them to do it e.g. we write documents - we need a Word processor (not a type writer), we send messages - we need email (not a faster mail trolley), we do strategic IT planning - we need a strategic IT planning solutuin (not more Visio, Excel, Word and Powerpoint documents). See: Providing professional tools of trade.