Lawson on EA supporting the Business

I think this is item is good and makes some key points

"... artifacts that are rigorous and approached as a science rather than as an art..."

"... instead of just discussing a business operating model through text ..."

"... you're not just documenting the business, you're analyzing the business and you're discovering quite a bit about the business ..."

"... they're not static deliverables. They're supposed to be living representations of the business and you should continue giving them attention and updating ..."

http://www.itbusinessedge.com/cm/community/features/interviews/blog/how-enterprise-architecture-can-support-the-business/?cs=47185&page=2

We also need to brings these concepts down stream into what business "analysts" and how requirements are discovered and elaborated e.g.

"... artifacts that are rigorous and approached as a science rather than as an art..." - what we need is are artefacts are rigorous and approached with semantic precision rather than as a story telling exercise in the "best seller list" book tradition

"... instead of just discussing a business operating model through text ..." - narrative is not always the best way of undertaking or recording analysis

"... you're not just documenting the business, you're analyzing the business and you're discovering quite a bit about the business ..." - and elaborating the Business Architecture as a part of defining requirements.

"... they're not static deliverables. They're supposed to be living representations of the business and you should continue giving them attention and updating ..."

Business Transformation Management, Business Architecture and Business Requirements

I think this item is on the money: http://www.baselinemag.com/c/a/Intelligence/Transforming-Data-Into-Information-849660/ [my comments inserted in square brackets]

"Transformation is an enterprise-wide activity, and the first step is to get a clear picture of the entire enterprise.

Most large organizations have used a variety of internal and external resources to document bits and pieces of the way they operate over time – organization charts, business plans, statements of policies and procedures, and the like. Many of these documents are of little value. They do not use commonly agreed-upon standards and terminology, are only partially complete, therefore they cannot be logically connected to formulate a cohesive picture. [So a common view of the Business context and Architecture is critical]

As a result, companies wrestle with a number of challenges:

- Prioritization hindered by competing business unit goals;

- Isolated process design resulting in loss of linkage to business objectives and unrealistic technology requirements;

- Overlapping business systems proliferating as a result of uncoordinated business units and mergers/acquisitions;

- Critical processes relying on temporary ad hoc “solutions” thrown together to meet immediate needs;

- Lack of asset reusability; difficulty communicating and defining standards;

- Difficulty keeping pace with technology change and vendor competencies;

- Enterprise architecture models that are too technical and detailed for anyone aside from those who designed them to understand and follow.

[- Projects are initiated with no clear explicit linkage back to the business context and with no ability to understand gaps and overlaps betweens the set of transformation initiatives]

For successful execution to be a remote possibility, an enduring transformation requires

... management framework that unites a company vertically – from the board room to the project team, as well as horizontally – across all divisions and including external partners and customers.

... strategic investment management, they have consistent processes for sponsoring, selecting and managing initiatives [So sound Business case development, based on the Business context and Business architecture is key].

... standardized means of structuring projects [and especially the key input to transformation initiatives such as projects i.e. the business requirements]

... ensuring that [transformation] are managed in accordance with enterprise standards.

... standards for determining the demand and the supply of resources—human, financial, fixed, and other—for future initiatives.

For these organizations, data has become information, which is managed effectively across the enterprise and used as the basis to make decisions accordingly. And, in large measure, this information is available through and managed in an integrated, enterprise-wide automated system that facilitates decision-making. These organizations understand both the specific strengths and the limitations of point solutions, and they have created management dashboards and other tools to make decision-making and management consistent. [This enterprise wide system contains their business context, business strategy, business architecture, business transformation initiatives and the associated requirements, the existing assets (including technologies) and views of new assets to be aquired). The systems isn't however focused on the detailed engineering of the technology assets (any more that it is focused on the detailed engineer of cars, building or other technologies).]

Now engaged in continuous process optimization: they learn, adapt, implement, and improve, in an ongoing cycle ... They conduct fully data-driven decision-making enabled by a consistent, coordinated, and integrated use of automation. Every professional has an appropriate level of access to enterprise-wide information, analysis, and management tools, and the enterprise makes this uniform, data-driven model fundamental to its way of doing business. [That is to say this critical information is just held within provence of a few strategists or architects]

“Every piece of business strategy acquires its true significance only against the background of that process and within the situation created by it.” .. the reality is those same principles and a transformative set of repeatable processes are what’s needed to build strong, healthier companies..."

Also see:

http://www.baselinemag.com/c/a/IT-Management/Beyond-Business-Models-427438/

Most large organizations have used a variety of internal and external resources to document bits and pieces of the way they operate over time – organization charts, business plans, statements of policies and procedures, and the like. Many of these documents are of little value. They do not use commonly agreed-upon standards and terminology, and are only partially complete. Therefore, they cannot be logically connected to formulate a cohesive picture.

More thoughts on EA

This is pretty good - http://www.infoq.com/news/2010/12/ba-model-ea

I agree

• "EA for the sake of doing EA ...flounders aimlessly in search of respect....IT needs to start thinking more like the business and less like engineers"
• "EA practitioners should be focused far more on enabling a deeper understanding of the purpose and capabilities of the enterprises they work in – to facilitate greater clarity of reasoning about strategic options and appropriate action – rather than taking on an often obstructive and disconnected IT strategy and governance role" ...
• "... capability map as a portfolio of business components ...the next level of details need only to be captured as new programs require them."
• " ...traditional views of EA (People, Process and Technology) are too simplistic to support the diversity of business models. [Need] ...business architecture assets targeted at different levels of abstraction and produced in a contextually appropriate way to facilitate a far greater federation in decision making and implementation.]
• "... you can no longer afford to ignore the ecosystem in which the enterprise operates"

I disagree that:

• it is "... impossible to keep a centralized view of how the enterprise works -at a cost that would justify the value of such a view. ...". However maintaining a view requires changes to methods and tooling so that view accretes as a natural by-product of other activities and does not require capture for its own sake (Cf. cadastral data capture).

Interfaces

I am often asked what the right way to record interfaces is. The answer is really that it depends what you want to know about the interfaces and that in practice you will probably want to record information at a number of levels

Let us examine another communications paradigm we are all familiar with – Bill communicating with Bob.

Should one record that:

1. Bill Communicates with Bob (remember communication may be multimodal)

2. Bill makes sounds with his mouth that Bob hears through his ears (and similar for other modes with different input and output interfaces).

3. Bill makes sounds that are communicated via a medium (e.g. air), or converted into electrical signals and transmitted via an electrical cable, to a switching mechanism etc.

See diagrams of three example options below

There are a myriad of other strategies e.g. Bill communicates with clients (and Bob is a client); or Bob's brain interprets the sounds and hears the words and emotional content, etc. Then there are the issues associated with the semantic content of the message e.g. do we want to record that Bill is communicating about Products, Pricing or whatever

Well it really depends on what we are trying to understand – if we want to understand communications flows in a organistion, or if we are designing a phone etc. It make be useful for different purposes and audiences to record this at many levels and to be able to relate these different views together.

Unsurprisingly the same is true when one considers who to record communications between applications. The way you record them varies based on the purpose. They may be recorded in multiple ways and it is very handy to be able have a way of see how all the different levels are related. But searching in vain for a single way of recording interfaces that will serve all audiences and all purposes is unlikely to be productive.

Traditional processes and EVP no good for EA

Even Microsoft is now saying "Traditional enterprise architecture processes do not work" (said by Gabriel Morgan, principal enterprise architect of Microsoft 10 days ago). He also said other things we have said for a long time e.g.

- "We have to prove IT’s value to deliver that market position"

- "We cannot develop a sustainable target architecture if we don’t know where we are"

So perhaps EAs will one day listen and stop doing what they have done i.e. using Excel, Visio and Powerpoint to try and do EA and look at what is actually required.

Dealing with complexity

I think this presentation indicates how useful visualisation are in dealing with complexity.

http://www.ted.com/talks/eric_berlow_how_complexity_leads_to_simplicity.html

It mentions that it is important to set back and embrace complexity, and then look at issues in context.

It also demonstrates how dynamic visualisations can be powerful in analysis where one can selectively hide, decompose etc. the views. And to my mind why static crafted hardcopy reports will often struggle to allow us to examine new issues that arise, and what-if analysis i.e. it is the ability to interactively explore the data from many perspectives that is critical to the insights.

It is only by understanding how to deal with complexity effectively and good using solutions and tools to deal with it are we going to get any better at making strategic transformation or optimisations of the increasingly complex systems that are large enterprises.

EA's need to understand money and be prepared to change

I do not know what to make of some central Enterprise Architecture functions who do not seem to appreciate the need for transformation or have a grasp of economics. Transformation is about changing how we do things. Economics must ultimately drive all EA activities i.e. a strive for business value, and understanding of cost alternatives etc. Or more accurately they have academic understanding they advocate for others but are relucant to apply to themselves.

These functions will happily create a central repository of information about the enterprise that is critical to executive decision-making and optimal excecution of initatives. Yet they persist seeking to create artefacts from this repository e.g. documents, PDFs rather than just let others in the enterprise directly access the information and keep it up to date themselves.

When asked why they don't provide access they cite cost of providing access and that people are used to getting documents and don't want to change.

I recently examined the cost issue. I calculated that the cost of providing direct access to accurate online information that can be drilled down in to, and dynamically visualised. I then equated that cost to the cost of the people's time. It showed the cost for access or visibility is less than the cost of 1 minute of the person's time. The cost to provide people the ability to interactively update the data (and then do what if) would cost perhaps 2-3 minutes of the person's time.

So clearly any rational analysis would suggest cost is not the issue, which leaves us just with the business change issue i.e. changing people's behaviour.

So frequently we have people earning 6 figure salaries who either don't seem able to work out that for the cost of 1-2% of their cost they could do a substantially better job; or don't really care about how good a job they do.