Richard Veryard on SOA

How Dashboards Work

2009-11-10T09:34:00.000Z

There are three ways of understanding a dashboard.

Symbolic. A dashboard simplifies and codifies What-Is-Going-On.

Imaginary. A dashboard creates an illusion of an accurate and comprehensive picture of What-Is-Going-On.

Real. The dashboard always falls short of representing What-Is-Going-On. There is always a shadow - something left over that eludes simple capture and representation, often remaining invisible or inaccessible.

Dashboard design and development often focuses on the symbolic - defining the contents of the dashboard as a aggregation of services and data feeds, defining the events that are to be displayed (for example as warning lights), and setting simple policies that set thresholds of attention for predictable events.

Some people seem to view this as a key element of systems thinking. For example Bas de Baar, who blogs under the name "Project Shrink", identifies Systems Thinking As A Technique To Find Project Problems and claims "If I have the right metrics I can ignore everything around me and focus just on the dashboard." He appears to justify this claim by comparing project managers with fish (Swimming Upstream The Information Flow). Fish may be reasonably well adapted to many environments, but they cannot deal with the complex threats posed by the much more intelligent dolphin, as I pointed out in my blog on Lean versus Complex.
However, an emphasis on the dashboard as a simple collection of metrics overlooks the way the dashboard is used within a socio-technical system. Isaac Asimov wrote a story called Reason in which a robot controlled a dashboard perfectly, while refusing to believe in any system beyond the dashboard, but of course that's science fiction.

If we imagine that the purpose of a dashboard is to support prompt and appropriate action in a wide range of normal and abnormal operating conditions, then it should support as much (human, organizational) intelligence as is required to maintain the viability and safety of the system in a given complex environment.

One of the lessons from the Three Mile Island disaster was that when something goes seriously wrong, all the red lights on the dashboard start flashing at the same time, and unless the people in charge of the system have some way of making sense of the emergency (emerging situation), they may make things worse rather than better. (Deming calls this tampering or meddling.)

The safe operation of the nuclear power plant is not just about the design of the dashboard, or about the training of the operators, but about the whole system producing good outcomes in all circumstances. In the Springfield Nuclear Plant, the risk comes not just from idiot operators (Homer Simpson) but from corrupt managers (Montgomery Burns).

Many dashboards are designed merely to aggregate and push information into a social system that the dashboard designer doesn't bother to understand. Prior to Three Mile Island, this was often true even in safety-critical situations. I trust that the safety-critical world has now learned this lesson, but dashboards in other contexts may not be so conscientiously designed and tested.

In management information systems, a dashboard focuses executive attention onto specific aspects of the business. But there seems to be an important difference between a random collection of KPIs or guiding ratios, and a joined-up view that helps the executive reason about the business as a whole system. The standard dashboard is lacking at least two elements of organizational intelligence: Sense-Making (helping the executive see how the different items are interrelated) and Double-Loop Learning (not just getting better at meeting fixed targets, but setting more appropriate targets).

So a dashboard needs to be designed to perform a clear function within an action-based command and control system, rather than merely a simplistic reporting function.

However, there are two traps here. Firstly the hubris of the designer, imagining that a complete understanding of a complex system is possible, or expecting to produce a perfect shadow-free dashboard. Secondly, the blinkered vision of the operator, staring at the dashboard and failing to look out of the window.

In any case, management-by-dashboard seems a pretty unauthentic and disengaged way of running a company. Perhaps it is ironic that HP, one of the leading technology companies of our time, boasts its co-founder Dave Packard as one of the earliest modern practitioners of the opposite technique - "management by walking around". (HP Timeline 1940s)

This blog is an edited version of my contributions to a discussion on the Lenscraft Linked-In group. Thanks to Aidan Ward, Geoff Elliott and Hans Lodder for their stimulating comments.

Enterprise Architecture and Economics

2009-11-02T16:11:00.000Z

@jpmorgenthal lays out the reason why enterprise architects should study economics.

But he is not talking about your grandmother's economics. He is particularly impressed by the precise evidence-based insights of the Freakonomics project, and points out the failures of established "best practice" in the economics field.

"Stephen Levitt undermines what many other Economists, experts and pundits before him rolled out as proven facts and only due to his keen mind and his approach to formulating the problem domain was he able to uncover that which his peers could not."

JP also points out the need for evidence-based decisions to be grounded in the specifics of the problem domain.

"It is the Enterprise Architect's role to ensure that the selection and approaches toward development of systems are sound relative to their business, not just other businesses. Moreover, where decisions are based on the work of other businesses' success, those successes need to be properly vetted to ensure that there is enough commonality between efforts, such that you could make the leap that your business will see similar results. Finally, assumptions and theories need to be tested by properly identifying the variables that need to remain static and then comparing; in essence normalizing the question to be homogenous in all situations."

"You cannot demonstrate the value of Enterprise Architecture if you cannot monetize or enumerate the value of all possible choices relative to the choices that are being recommended or those that have been made. Moreover, it's critical that these analyses are carried out over enough time that short-term wins don't supersede long-term potential gains."

I completely agree with JP's demands, but I wonder how many economics courses you could learn these skills from.

JP concludes

"It is here that Enterprise Architects, especially those we call Chief Architects, truly show their mettle. It is their experience, coupled with the ability to focus on the right set of variables, understanding the impact of change of those variables and being able to communicate that in a way that allows the business to make effective business decisions, which sets top notch practioners apart from Sr. Software Engineers that the organization placated with a title to keep them happy so they wouldn't leave."

So what is the combined market share of EAs with these skills? A tiny fraction of a percent? And what would be the implications of this percentage on IT decisions?

Ecosystem SOA

2009-10-29T13:47:00.000Z

The SOA world is finally catching up with some of the ecosystem ideas that I published in my 2001 book on the Component-Based Business, and developed further in several articles and presentations for the CBDI Forum over a number of years.

Supply and Fit (September 2000)
Identifying Components 2 (October 2001)
Opportunities in the Insurance Ecosystem (December 2004)
Business Strategy Planning for the Service Economy (May 2006)

The biological approach to creating business and software services is radically different to the solution-driven approach, and is based on biological and ecological metaphors.

First we identify an ecosystem, which may contain both human users and existing artefacts.
Then we identify services that would be meaningful and viable in this ecosystem.
Then we procure devices that enable the release and delivery of these services into the ecosystem.

I previously defined Three Types of Requirements Engineering, and we can map these onto different styles of SOA.

Solution-Driven (Specific)	Solution-Driven (General)	Evolution-Driven
Identify Business Problem Identify "Users" Negotiate Requirements Define Solution	Identify Domain Identify Domain Experts Define Requirements Design Solution Kit	Identify Ecosystem Identify Services Procure and Release Devices
Experimental SOA	Enterprise SOA	Ecosystem SOA

(Some people use the term Web Oriented Architecture (WOA) for what I'm calling Ecosystem SOA.)

If we regard these as phases of maturity, then we can have a straightforward roadmap from left to right, as in for example the CBDI SOA Roadmap. However, some organizations may need to tackle these styles of SOA in parallel rather than in sequence.

A service portfolio plan for Enterprise SOA can be based on an enterprise model that identifies the capabilities of the enterprise and clusters these into domains. In the CBDI Forum's SAE methodology, the domains are classified as Core and Contextual according to a matrix derived from Geoffrey Moore. (Note how the domains migrate around the matrix over time.) See for example my blogpost Tesco outsources core eCommerce.

A similar model, derived from Amin and Cohendet's book Architecture of Knowledge, explicitly describes Core and Periphery in terms of knowledge intensity. In other words, the reason something is classified as Core is because it encapsulates some important (strategic) knowledge.

For example, an insurance company knows more about insurance than about cars, so when providing car insurance it may decide to partner with other organizations that know more about cars than about insurance. This results in a composition of insurance-related services and car-related services (for example, determining the insurable value of a used car). Such compositions can be either directed (in other words, composed by a single dominant player) or collaborative (in other words, emerging from the interaction between multiple players within the ecosystem).

For example, an online retailer knows about her products and services, but doesn't wish to become an expert in credit card handling, or to be responsible for data protection and security, so she delegates these concerns to a specialist provider that knows more about these matters.

Similar considerations can apply to industry consortia, such as ACORD (for the insurance market). ACORD can define generic service-based assets (such as models, schemas, interfaces and so on) for insurance. However, insurance companies will also wish to use generic service-based assets to cover requirements that are not insurance-specific, such as customer management or complaints handling, where ACORD may not be able to add any knowledge-value, and it would be appropriate for ACORD to regard these as peripheral to its own activities rather than core.

So one approach to Ecosystem SOA is to push out from the enterprise into the ecosystem. John Hagel calls this Inside-Out Architecture, which he contrasts with Outside-In Architecture. (See my post on Outside-In Architecture.)

An Outside-In Architecture starts with a model of (the flows of) knowledge and value in the ecosystem as a whole. The strategic question for an enterprise is how to find way of both contributing value to the ecosystem, and drawing value from the ecosystem, through the provision of ecologically viable services.

For example, a telecoms company might reasonably consider that its core competence is something to do with communications. So a positional strategy would drive it to a dominant position in the middle of a large communication ecosystem, providing a platform of services that add value to a diverse range of communication activities by other people. The dominant position would allow it to negotiate a strong share of the value generated.

However, respect for the ecosystem would lead it to leave sufficient value to third parties to maintain the economic health of the remainder of the ecosystem. Instead of a simple positional strategy, a relational strategy (based on mutual trust with ecosystem partners) should produce a more sustainable and ecologically sound ecosystem.

Is Enterprise Architecture a Profession?

2009-10-27T11:07:00.003Z

The Center for Advancement of Enterprise Architecture Profession (CAEAP) is in the process of developing an EA Professional Practice Guide that, among other things, will define what it mean to be an Enterprise Architect. Is Enterprise Architecture a profession, or does it have any reasonable chance of becoming a profession in the foreseeable future?

While I don't fully agree with the Wikipedia definition of Profession, I think it identifies a lot of characteristics commonly associated with professional status, and EA lacks many of these characteristics.

Here are three reasons why I don't think EA is (yet) a profession.

1. Organizations claiming to represent enterprise architects have relatively few members.

2. There are no meaningful sanctions against maverick or incompetent practitioners.

3. Although some universities are starting to offer degrees in Enterprise Architecture, for the foreseeable future this qualification will only be held by a tiny fraction of practitioners, mostly at the inexperienced end.
There are some worthy goals on the CAEAP homepage, which I think accord with my view of what counts as a profession, but these are currently merely future aspirations. I acknowledge that CAEAP seems to be putting a fair amount of effort into this, but this doesn't justify some of its more extreme supporters trying to confuse AS-IS with TO-BE. I shall be prepared to regard EA as a profession and the CAEAP as a legitimate representative body if and when these goals are ever achieved. For the time being, I think it is more accurate to regard EA as an aspiring profession than an established one.

However, the present interest in CAEAP is almost entirely coming from enterprise architects themselves, rather than from the people they are providing services to, and I think this may be a major obstacle in the CAEAP's achieving its goals.

Another major issue, in my view, is that of professional accountability. In healthcare, professional and ethical responsibility is clearly focused on the patient (as the "consumer" of healthcare services). In the legal profession, a lawyer represents a specific client and there are clear conflict-of-interest rules preventing a lawyer representing multiple parties in the same case. The CAEAP Value Map recognizes the need for "professional accountability" as well as "responsibility to multiple stakeholders and seek(ing) balance among potentially conflicting demands". But to which of these multiple stakeholders is the Enterprise Architect ultimately accountable, and who has the ultimate authority to resolve conflict?

I believe that CAEAP should be talking not just to EA practitioners but also to the consumers of EA services - whoever they might be - and I don't see any sign that they are doing this. (However, they are happy to accept sponsorship from vendors, who clearly have a commercial interest in influencing enterprise architects. This kind of sponsorship is perfectly acceptable for a trade body, but raises questions for an organization that wishes to establish itself as a proper profession. The Royal College of Midwives doesn't take backhanders from drug companies, does it?)

CLARIFICATION: Microsoft and IBM sponsored the CAEAP summit. @jpmorgenthal insists that this is a conference, distinct from the organization itself, and argues that the organization itself is not sponsored by vendors. That may be strictly true, but it is difficult to avoid the impression that sponsoring the conference significantly benefits the organization.

Jon Ayre challenges this point. "Consumers choose whether or not to consume. If EA doesn't provide right services consumer will reject it."

Of course, with some exceptions, professionals cannot force their services upon their clients. But there is still some external validation - a practice becomes a profession not because people inside the practice want it to be, but because people outside the profession have respect for it. Members of a profession may receive public or institutional funding for some of their activities, and may have a privileged status in legislation and regulation.

As far as I can see, all of CAEAP's directors and trustees are EA insiders. So where is the external voice? Who represents the stakeholders of EA?

Is Enterprise Architecture Dead?

2009-10-27T09:21:00.000Z

I can't see much recognition or respect for the value of "Enterprise Architecture" except among the ranks of EA practitioners. In many organizations, the function of enterprise architecture is squeezed or marginalized, if not rejected altogether.

The attempt by the CAEAP to turn EA into a "Profession" is not going to address this problem. The desire for professional status is not coming from the demand-side (CEOs wishing to distinguish genuine practitioners from charlatans) but from the supply-side (like teenagers wanting to be taken seriously). People who think EA is a waste of space are not going to be reassured by the existence of a cartel of people with impressive-looking certificates.

Meanwhile the most experienced and able practitioners are getting on with the work, engaging with the business rather than worrying about preserving a label with such negative connotations.

I have been mulling on this post for a while, but I am now prompted to complete it by CBDI boss David Sprott, who has just produced a good post on The Death of Enterprise Architecture. Perhaps responding to the fuss about the Death of SOA, which exercised a few minds earlier in the year (see my post Has SOA Gone for a Burton?), he suggests that it is Enterprise Architecture that is dead - not just in need of a new label but in need of a new concept.

David proposes Smart Ecosystem Architecture. He refers to some of the CBDI reports I wrote about ecosystems in various industries (Airlines, Insurance, Public Sector) and argues that it's not about the enterprise any more.

"Various influences particularly Complex Event Driven Architecture and Smart Business and IT are strongly predicated on optimizing business design and processes involving all the ecosystem stakeholders."

Not just engaging with the business, then, but looking beyond the business into the demand environment. See my paper (with Philip Boxer) Taking Governance to the Edge (Microsoft Architecture Journal, August 2006)

Event-Driven Enterprise Architecture

2009-10-26T10:35:00.000Z

@toddbiske responded to @jeffrschneider 's question about the trigger for EA services.

Todd distinguishes between two kinds of service, which he calls request/response-style and event-driven services.

"There are services that are explicitly invoked at the request of a consumer, and then there are services that are executed in response to some event. In the latter case, the team providing the service is the one monitoring for the event. If some other team was monitoring for it, and then told your team to do something, then we’re back to the request/response style with one team acting as consumer and the other acting as the provider."

But surely a request is an event? The EA team may have many conflicting demands on its time and attention, and so there is always a decision (perhaps driven by some policy) whether and how quickly to respond to a given request.

A kind of event that might trigger EA services is one that looks like "we think we might have a problem in such-and-such area". (This is what Philip Boxer calls a P-type service - rcKP - services at the edge.)

In this example, "we" could be the EA team or the EA customer or both together. The service might include clarifying whether there really is a problem at all, not just solving a known problem.

The event triggering this kind of work is typically a weak signal. There are usually more possible problems than we actually have time to work on, so the existence of a problem is not a sufficient trigger for activity.

One interesting question here is how the event-driven EA actually works. The EA team must have some view of a complex and dynamic world to which it is attempting to add value, that allows it to organize its work. In other words, it needs a model (possibly implicit, but preferably explicit). But what model is this? Not just the enterprise model itself, not just the enterprise architecture framework (TOGAF or what have you) but something else as well.

Towards an Architecture of Privacy

2009-10-25T13:41:00.000Z

@futureidentity (Robin Wilton) posted some interesting ideas about Identity versus attributes on his blog.

"For an awful lot of service access decisions, it's not actually important to know who the service requester is - it's usually just important to know some particular thing about them. Here are a couple of examples:

If someone wants to buy a drink in a bar, it's not important who they are, what's important is whether they are of legal age;

If someone needs a blood transfusion, it's more important to know their blood type than their identity."

However, there is an important difference between Robin's two examples. Blood transfusion is a transaction with longer-lasting consequences. If a batch of blood is contaminated, there seems to be a legitimate requirement to trace forwards (who received this blood) and backwards (who donated this blood), in order to limit the consequences of this contamination event and to prevent further occurrences.

There is a strong demand for increasing traceability. In manufacturing, we want to trace every manufactured item to a specific batch, and associate each batch with specific raw materials and employees. In food production, we want to trace every portion back to the farm, so that salmonella outbreaks can be blamed on the farmer. See Information Sharing and Joined-Up Services 1, 2.

Transactions that were previously regarded as isolated ones are now increasingly joined-up. The eggs that go into the custard tart you buy in the works canteen used to be anonymous, but in future they won't be. See Labelling as Service 1, 2.

Of course, there is also a strong demand for increased auditability. So it is not enough for the barman to check the drinker's age, the barman must keep a permanent record of having diligently carried out the check. It is apparently not enough for the hotel or bank clerk to look at my passport, they must retain a photocopy of my passport in order to remove any suspicion of collusion. (The bank not only mistrusts its customers, it also mistrusts its employees.)

There is a large (and growing) class of situations where so-called joined-up-thinking seems to require the negation of privacy. I am certainly not saying that this reasoning should always trump the needs of privacy. But privacy campaigners need to understand that all transactions belong within some system of systems, and that this provides the context for the forces they are battling against, rather than pretending that transactions can be regarded as purely isolated events. The point is that authorization is not an isolated event, but is embedded in a larger system, and it is this larger system that apparently requires greater disclosure and retention.

@j4ngis asks how long chains to use for traceability. What "length" of traceability is sound and meaningful? How do we connect all these traces? And also backward and forward in the "chain". For how long should records be kept?

Should we also know the batch number for the food that was given to the chicken that laid the egg you included in the cake?
Do we have to know the identity of the blood donour after six months? 10 years? 100 years?

The trouble is that there is no rational basis for drawing the line. It is always possible that some contamination in the chicken feed might affect the eggs and thereby the custard tart. It is always possible that the hyperactivity of certain schoolchildren, or the testosterone levels of certain adults, might be traced back to some contamination in the food chain. It is always possible that some obscure data correlation might one day save lives or protect children. And given the vanishing costs of data management, even a faint possibility of future benefit appears to provide sufficient reason for collecting and storing the data.

Robin clearly supposes that attribute-based authorization is a "Good Thing". I am sympathetic to this view, but I don't know how this view can stand up against the kind of sustained attack from a certain flavour of joined-up systems thinking that can almost always postulate the possibility (however faint) of saving lives or protecting children or catching criminals, if only we can retain everything and trace everything.

For my part, I have a vague desire for anonymity and privacy, a vague sense of the harm that might come to me as a result of breaches to my privacy, and a surge of annoyance when I am required to provide all sorts of personal data for what I see as unreasonable purposes, but I cannot base an architecture on any of these feelings.

Traditional arguments for data protection may seem to be merely rearguard resistance to integrated and joined-up systems. Traditional architectures for data protection look increasingly obsolete. But what alternatives are there?

Asymmetric Demand for Defence Equipment

2009-10-15T22:21:00.060+01:00

An independent review into the way the MOD buys equipment for Britain's Armed Forces has been published today, Thursday 15 October 2009. [Report, MoD News Article, BBC News]. Key finding.

"The Ministry of Defence has a substantially overheated equipment programme, with too many types of equipment being ordered for too large a range of tasks at too high a specification. This programme is unaffordable on any likely projection of future budgets."

That situation might sound familiar to a lot of managers, not just in the defence sector.

The report makes some favourable comments about the Through Life Capability Management (TLCM) programme, but indicates a lack of hard financial data that would be required to make quantitative decisions. There has been some discussion along these lines published in the RUSI Journal, including Agility and Innovation in Acquistion (Feb 2008) and The Meaning of Value-for-Money (Feb 2009).

The explanation for the current crisis can be found in the essential multi-sidedness of the defence acquisition ecosystem. Traditional cost accounting approaches (such as activity-based costing) fail to address the complexity of this multi-sidedness, and researchers are urgently seeking alternative cost accounting methods appropriate for complex systems-of-systems.

One of the key issues for Through Life Capability Management is that any errors or omissions in the long-term equipment programme must be repaired through what are known as Urgent Operational Requirements (UOR), which over the long haul can prove far more expensive and inflexible than the planned equipment.

The report also praises the Smart Acquisition programme, and expresses regret that the disciplines of Smart Acquisition have been somewhat diluted by recent reorganization.

Is this report only relevant to the defence sector, or can other sectors glean anything useful? My view is that the complexities of multi-sided markets and asymmetric demand can be found in many, perhaps most sectors. And the question of coordinating effectively between short-term and longer-term spending can be found in many domains, notably IT. I have little doubt that whatever management tools and techniques are developed by the MoD and its partners to address this problem will eventually trickle into civilian management.

Online pricing practices to be regulated?

2009-10-15T20:51:00.000+01:00

The British Office of Fair Trading (OFT) is starting an investigation of online pricing practices. [BBC News, 15 October 2009]

Type	Description	Typical Offenders
Drip pricing	Consumers only see an element of the price upfront and end up paying much more due to optional or compulsory extras	Airlines, car hire firms and insurance companies
Time-limited offers	For example, sales that finish at the end of the month or last for one day only.	Carpet stores and furniture sellers
Baiting sales	A company advertises discounts to attract visitors whilst having few items at that price on sale
Reference prices	Artificially inflating the pre-sale price of an item in order to make the discount look more attractive.	Companies offering cruises or selling furniture. Supermarkets
Complex pricing	It is difficult for a consumer to assess an individual price, such as with three-for-two offers and 'free' add-ons.	Mobile phone companies, supermarkets and computer stores
Customized pricing	Prices are individually tailored using information collected about a consumer's internet use
Price comparison websites	There may be some hidden financial ties or other collusion between an apparently independent comparison site and the suppliers whose prices they are comparing

I have talked about some of these pricing schemes and scams before, in particular complexity-based pricing. I've also talked about ways (such as the infamous Ghetto Latte) whereby consumers can get a better deal than the service provider intended. All this kind of thing results in chronic distrust between service provider and service user, and excessive transaction costs. Might seem like a classic argument for regulatory intervention, if we could really believe that would make the situation fairer. What do you think?

Disruptive business model for telephony

2009-10-09T01:28:00.000+01:00

@martingeddes believes that "voice telephony is a market full of potential for the service providers, applications developers and innovators, and full of promise for both end customers and upstream business organisations such as contact centre operations" (New business model aims to bring voice back, BT plc Innovation).

"What would really be disruptive is the complete turning upside down of the telephony business model."

Martin identifies three key challenges, which roughly correspond to the three asymmetries identified by Philip Boxer and myself in Metropolis and SOA Governance (Microsoft Architecture Journal, July 2005).

Martin's first challenge is how users connect. “In the case of contact centres, traditional outbound calling can be unproductive for agents with an average of around fifty per cent of an agent’s time being spent on useful calls.”	The third asymmetry requires separating out the different contexts of use
Martin's second challenge is how upstream business and end-users interact. “This is where we would need to integrate our understanding of the customer with what the upstream organisation wants to do to interact with them. Small, network and applications-based intelligent telephony improvements that enable this to happen could lead to profitable interactions for businesses and better experiences for end-customers.”	The second asymmetry requires separating out business models that can organize supply from the solutions that are on offer.
Martin’s final challenge relates to how transactions will work. “The key here is developing and implementing intelligent telephony services.”	The first asymmetry involves separating out technology from the supply of specific products.

To become better at capturing asymmetric forms of demand, an organization such as BT needs leadership that will enable it to do two things:

Take power to the edge of the organization: The people at the edge of the organization with the relationship to the asymmetric demand must be able to organize the business model they need to capture that demand.

Develop an agile infrastructure: providing business services that can be orchestrated and composed at the edge in response to the particular forms of demand they are targeting. This then allows the supply-side of a business to extract economies of scale or scope when providing support across multiple business models.

Is Architecture the Enemy of Innovation?

2009-09-21T12:55:00.000+01:00

asks @EnterprisingA . Well, obviously architecture is not the avowed enemy of innovation. As Jon points out, they ought to be on the same side, because there are some strong shared values.

But surely the real question is not whether they ought to be helping each other, but whether (good intentions notwithstanding) they actually do support each other's efforts more than they (inadvertently) hinder and interfere with each other.

I think there is some evidence for the proposition that Architecture and Innovation don't actually collaborate as well in practice as they ought to in theory. This does not necessarily mean a critique of Architecture as such, but a critique of current "best practices".

Jon talks about the TO-BE architecture, but I am also interested in the TO-BE practice of architecture.

Economics of agility 2

2009-09-02T14:46:00.000+01:00

In my previous post on the Economics of Agility, I noted how little material has been published on this topic.

As Nicholas Whittall and Philip Boxer point out in their contribution to the recent debate on The Meaning of Value-for-Money in Defence Acquisition (RUSI, February 2009), there is an important link between agility and alignment. See also their earlier piece on Agility and Innovation in Acquisition (RUSI, February 2008).

The first observation is that defence acquisition - just like systems acquisition most anywhere - operates on a much slower tempo than the requirements of the business. The "business" of a military organization is running military campaigns; thus when writing for the defence community, Whittall and Boxer refer to the Campaign Tempo and the Acquisition Tempo.

The second observation is that there is a complex set of activities (such as orchestration, customization, and improvisation) involved in bridging between Demand (the demands of the campaign or business) and Supply (the procurement of specific systems and devices). These activities operate on an intermediate tempo, which Whittall and Boxer call the Alignment Tempo.

"Meeting the campaign tempo then depends on the alignment tempo possible, which in turn depends on the acquisition tempo at which gaps can be filled. Any slowness in acquisition tempo leads to increased bricolage and process short cuts to enable the alignment tempo to keep up with the campaign tempo. Thus, ‘agility’ finds its richest expression in the ability of the alignment tempo to meet the required campaign tempo at the lowest cost – i.e. to maximise the value-for-defence."

The challenge is then to produce just enough variety within the acquisition to optimize the economics of alignment. Boxer has developed a technique of Cohesion-Based Costing (not yet published), which "offers a means to attach a value to the cost of introducing flexibility". This kind of technique will clearly be of enormous benefit within the SOA world.

SOA as Multi-Sided Platform

2009-09-02T08:39:00.000+01:00

One of the ways to think about the complexity of SOA is as a multi-sided platform.

Some of the pioneering work on multi-sided platforms has been published by Andrei Hagiu at the Harvard Business School. (Follow links from his homepage to some of his recent papers.)

In November 2006, I posted a brief commentary on Two-Sided Markets, referencing his work, and indicating its relevance to a service-oriented business strategy.

As yet, relatively few people have made the connection between multi-sided markets and SOA. In June 2007, Richard Friedman posted something useful on Multi-sided Platforms for Business or Software, and I found a paper entitled Optimizing the Supplier Selection and Service Portfolio of a SOA Service Integrator presented to a 2008 conference by a group of German researchers.

One of the attractions of SOA is that it should allow people and organizations to collaborate more effectively and cost-effectively. From the supply-side perspective, this means collaboration between the users of your platform. Your platform may or may not support a rich and open variety of collaborations, including mashups and other third-party initiatives, and this richness and openness significantly affects the demand-side value of your SOA platform.

The critical economic question here is not the economics of scale on the supply-side but the economics of scope and agility on the demand-side. Thus the critical question for platform design is how open/closed these platforms are, and the extent to which they constrain (overdetermine) or enable (underdetermine) demand-side activity.

Has EA gone for a Burton?

2009-08-29T16:47:00.001+01:00

@mikerollings, an analyst with the Burton Group, invited Brenda Michelson to check out his free report Enterprise Architecture is more than Engineering, so I thought I'd take up his invitation as well.

Mike Kavis had started the discussion with a comment on Twitter: "Everybody is struggling with the value of EA for us little guys while I see it each day." In reply, Brenda had suggested that the problem was "many equate EA w/jumbo frameworks and rigid governance, rather than set of values and practices for capability delivery". This was what prompted Mike Rollings to issue the invitation.

Meanwhile, Aleks Buterman claims to have a "secret sauce to measuring value of EA" but won't let anyone see the recipe. I think this is a pity, because I believe a credible measurement formula needs to be open, transparent and calibrated on a range of different organizations. I hope he's working towards making something public.

Before we look at Mike Rollings' own report on EA, let's take a quick look at his criticism of Gartner, provocatively entitled Gartner wakes out of an EA induced coma ... (11 August 2009)

"Thank you Gartner for validating my claim that prevailing wisdom about EA is washed up and the pursuit of building an EA admiration society is not the predominant goal of EA. Thank you for further illustrating that living in a mythical world where EA is king is just dead wrong."

And he continues with a plug for his own firm

"Want a new approach for enterprise architecture? Read Burton Group's EA research."

So I did (see edited highlights below). Mike's report identifies three familiar problems, and then makes four fairly bland recommendations. Is this really a new approach? Unfortunately, there is a "disconnect" (one of Mike's favourite words) between these two sections, so the recommendations don't demonstrably deal with the problems. (Indeed, readers with real experience of EA may see ways in which Mike's recommendations might make some of his problems worse. For example, there are several plausible arguments for having an eclectic approach to EA, but it isn't clear how this is going to solve the problem of disconnected EA artifacts.)

While Mike's understanding of EA problems appear to be underpinned by his adhoc observations of EA in practice, there is no sign that his recommendations are based on anything more than common sense. Therefore nothing to stop him, when he is arguing with Gartner, coming up with an entirely new set of recommendations (see below).

In my opinion EA is in crisis, and it needs a lot more than disconnected recommendations based on common sense and/or prevailing wisdom. More than engineering perhaps, but where is the value proposition for Enterprise Architecture?

Edited highlights of Burton report

Problems facing EA

EA has minimal influence. I have spoken with teams that could not gain traction - their artifacts were disconnected from each other and lacked relevant guidance. I have also seen beautiful architectures ... that go unused.

Lack of participation and commitment. A lack of participation can fuel and be perceived as the ivory tower syndrome, which is a natural outcome of organizational isolation.

Mismatch with the domains of the effective CIO. Most EA programs are heavily skewed towards a single domain: implementing and managing technology.

Burton recommendations

Avoid using frameworks like a precise cookbook for architecture. A variety of methods (unspecified) should be used to capture, communicate and share design information. Enterprise architects employ both manual and mechanical tools in a purposeful way.

Align with your organization's operating model. The operating model is fundamental to the business. Effective EA programs align with the operating model and do not over-reach the level of standardization or integration determined by the business.

Be results-oriented. Successful EA programs are action-oriented and help get things done. People understand how the EA program works. They also understand the contribution that EA team members make as participants in other IT processes.

Do not settle for comparisons: Understand what needs to improve. Maturity assessments can be very elaborate. At a minimum they should evaluate the following EA program characteristics: Business Alignment, EA Program Oversight, Communication and Change Leadership, and Governance. By examining these characteristics with an open mind toward change, an improvement plan can be created to improve EA related outcomes.

New recommendations (Mike Rollings via InfoQ, 26 August 2009)

Rule-Breaking: If rules are being broken it can signal outdated thinking and the need for something different.

Entrepreneurial: Value of IT comes from being transparent about your business contribution.

Self-Educating: Embrace varying ideas, collaborate vigorously and respectfully, assure that you tap into the variety of perspectives that exist.

Bonding: The lack of influence is probably a main cause of your EA coma.

Visionary: Be a leader, be a team player, participate and collaborate.

Economics of agility

2009-08-25T23:35:00.006+01:00

@andygreenawalt says he hasn't seen much on the economics of agility. "Open source breaks $ vs security battle. Investment impregnation kills agility."

Andy's comment arose from a discussion of agile security. I have written several pieces for the CBDI Forum on agile security - see the CBDI resource portal.

More generally, the economics of agility is critical to the business case for SOA, and a few of us have sometimes called it the SOA Sweet Spot (March 2007).

Looking around, I also found some work by Marc Rix called Bottom-Line SOA: The Economics of Agility (April 2007). See comments by Alastair Bathgate, Bill Barr and Gary Smith, with Marc's response.

And back in 2004, Stuart Robbins wrote something on the economics of agility for grid management (pdf).

But compared to the huge amount about the economics of scale (sharing, reuse), that's not much is it?

Organizational Memory

2009-08-21T18:26:00.003+01:00

Are social networking tools the solution to improving organizational memory (asks @EffectiveCIO Chuck Musciano)? Chuck's blog Legs and Memory suggests a link between memory and efficiency: "Forgotten items create more work, both at home and on the job."

Now that would be easy enough if nothing ever changed, and if last year's best practices still worked. But as Chuck points out, formal guides and detailed documentation fail because of continuous change. There is a tension between efficient adaptation and effective adaptability.

So Chuck argues that organizational memory is best retained in the heads of the people in the organization. And because captured organizational memories fade rapidly over time, you must reinforce your organizational memories, by constantly revisiting and updating them.

What's the role of social networking tools here then? Chuck doesn't believe that these tools are yet up to the job of real-time knowledge capture, and falls back on the old favourite - finding the person who knows what we need. Better than nothing perhaps, but way short of what is needed.

What is needed for organizational intelligence is the ability to use organizational memory without being controlled by the past. In his post (some) rules are meant to be broken, Brett Miller makes this point very well.

You can see this in the way many organizations apply the idea of “best practices”: capture past practices that worked and apply those practices, as is, to future situations that are similar. While this works fine for what I call “information” processes - and is a critical step in helping any organization improve - it is not appropriate for “knowledge” processes. ...

... This is not to say that past experiences should not be exploited in creating/acquiring new knowledge. Except for the rarest of occasions, most new knowledge created today is derivative of something past. It is important to know what has come before and learn from the successes and failures of others. The rules that come from those past lessons then become the framework for the future.

But of course organizational memory does not only consist of rules (best practices), but all sorts of other knowledge (including evidence, interpretation and stories) that may be relevant to developing next practice. A lot of this knowledge will surely be maintained in electronic form, not just in people's heads, some structured or semi-structured, using a broad range of social software.

Furthermore, evolving practices (organizational learning) will typically require collaboration between different people across the enterprise, and we may reasonably hope for software tools to support this learning.

Once upon a time, information systems maintained a clear distinction between highly structured data (in old-fashioned databases) and loosely structured information (in a wide range of formats, including Office). But we now need to find new ways of integrating this information to support the intelligent organization.

Enterprise Suffix - Companies as Categories

2009-08-20T11:34:00.006+01:00

@tetradian Tom Graves is annoyed at Enterprise 2.0. He (rightly) complains that the term as defined by Andrew McAfee refers to software, and tries to construct an alternative definition that is more business-oriented.

While I agree with his complaint, I am not convinced that a business-oriented definition of "Enterprise 2.0" is a worthwhile exercise. The "2.0" suffix is inextricably linked to the software paradigm; it is a metaphor for strict version control, and really only makes sense to software engineers and dictators. To produce the Third Reich (or as we should now call it "Reich 3.0") required a massive amount of centralized control and alignment (known as Gleichschaltung).

Software engineers who want to sound cool often use names instead of numbers. Apple operating systems are named after large cats, so we might have something like Enterprise Snow Leopard. (Thanks to Ron Tolido.) Microsoft plays this game as well - see my post on Google and Longhorn.

Software people may describe enterprises in terms of version numbers, but how do business people describe enterprises? Usually by comparing with something else. Listen to how entrepreneurs bid for venture capital. "It's going to be like eBay with a dash of vodka." "It's going to combine the innovation of Google with the popularity of er Google." In other words, they tell stories and paint pictures.

At any given time, there are a few companies that everyone wants to emulate - not just in terms of market share and profit, but also in terms of the internal management and organization - typically based on descriptions in the popular business literature. One of the early classics of this genre was Peters and Waterman, In Search of Excellence, which held up several American firms for admiration and emulation. (These recommendations look really dated now; and as Jason Cohen points out, Business Advice is Plagued by Survivor Bias.) In the heyday of quality management, many people tried to emulate Xerox and Motorola. More recently, Joshua Cooper Ramo, in a book called The Age of the Unthinkable, identifies Google and Hizb'allah as two of the most innovative organizations of our time.

Therefore if we must have an enterprise suffix, and if we want this to be meaningful to business people, let's use well-known companies as the categories. So if you want to emulate Google, then you need to implement Enterprise-a-Google.

Not perfect I agree, but anything's better than these dammed version numbers.

The Calculus of Cost

2009-08-07T11:38:00.005+01:00

@fbjk2000 (Florian Krueger) poses a set of questions about costs, under the heading Review your calculus of cost. The questions are fair, but the heading is wrong: Florian's questions are all about reviewing cost, and nothing about the calculus of cost.

Cost review looks either at the total cost (is this too much for customers to bear) or at individual cost items (are we paying too much for this item)?

Cost calculus looks at how the total cost is composed from individual cost items, understanding how costs are added and subtracted and multiplied, getting an appropriate balance between fixed costs and variable costs, clustering expenditure to achieve cost synergies, and so on.

Here are some examples

In a traditional high-volume non-volatile business, cost reduction can be based on economies of scale, with high fixed costs and low variable costs.
In a volatile business, it may make more sense to reduce the fixed costs and accept higher variable costs.
Purchasing several different items from the same supplier reduces transaction costs and allows bulk discounts to be negotiated, but may not achieve the lowest price for every item.
Allocating costs to a given project can yield widely different results, depending on the formula that is used.

For any reasonably large business or IT operation, questions like these require non-trivial mathematics. And you shouldn't use words like "calculus" unless you are prepared to do that.

Is this just quibbling about semantics? Not at all. Business people may worry about costs, but business analysts and business architects need to pay attention to the structure of costs rather than the tactical details.

Loose Coupling: Innovation and the Web

2009-08-06T13:28:00.003+01:00

"Cosy social networks are stifling innovation", according to an article in the New Scientist (5 August 2009).

This is a familiar argument in a new context. It has often been argued that corporate culture can inhibit innovation, and that groups responsible for experimental products and processes tend to perform better if they are put into a separate organization unit at some distance from the main offices. In recent years, many companies have set up R&D units in special science parks, co-located with similar units from other other companies, usually with links to a nearby university. This is essentially applying architectural thinking to the geographical location and distribution of certain classes of capability, and reflects a common belief in the importance of these factors.

But interaction and clustering is nowadays much less dependent on physical geography, and much more dependent on virtual online communities and networks. The New Scientist article quotes Viktor Mayer-Schönberger of the National University of Singapore, who argues that today's software developers work in social networks in which everyone is closely linked to everyone else. "The over-abundance of connections through which information travels reduces diversity and keeps radical ideas from taking hold."

What Mayer-Schönberger sees as an over-abundance of connections is actually another form of tight coupling. If we want to build the capability for radical innovation, we need to create a decoupled space to support a loosely coupled knowledge cycle. Which means careful attention to the effects of social networking and organizational intelligence.

Is Enterprise Architecture a Science?

2009-07-09T20:02:00.004+01:00

asks @RSessions (Roger Sessions)

I have long argued that the answer is no. What passes for knowledge in enterprise architecture is largely a combination of anecdote and received opinion. Intellectual effort is devoted to hierarchical forms and elaborate classification schemas, based on abstract reason rather than empirical measurement; this kind of work looks more like mediaeval scholastic philosophy than modern science.

In comparison, the followers of Christopher Alexander seem like nineteenth century gentleman scientists, carefully collecting specimens from which they try to infer useful principles and patterns. Alexander's four-volume masterpiece on the Nature of Order is a brilliant and fascinating work, which I think every enterprise architect should read (in their spare time), but it's not exactly suitable as an everyday handbook.

In order for enterprise architecture to qualify as a science, it has to follow scientific method. Now I am pretty broadminded about what counts as scientific method, but it's more than mere predictability. (Card games are predictable, but that doesn't make cribbage a science. Roger says if card games were predictable, he'd be a rich man. But if card games were not predictable, the casinos would go broke.)

Anyway, you can get predictability from art. I saw Dave Crosby on a documentary once, criticizing the fact that the Eagles' concerts were note-for-note predictable, CSNY preferring a slightly looser style in response to each audience. So what if EA's an art, asks @HotFusionMan (Al Chou).

Peirce understood the limitation of scientific method, holding "that slow and stumbling ratiocination can be dangerously inferior to instinct, sentiment, and tradition in practical matters" (Wikipedia).

So does it matter if (as I believe) Enterprise Architecture is not a science? The key question that raises is - what is the source and status of EA knowledge, and how can we ever resolve matters of opinion, except by obscure mediaeval argument?

SOA Retrospective

2009-06-30T19:17:00.004+01:00

As this is my last day as a full-time employee of the CBDI Forum, I thought I'd permit myself a little retrospective discussion on Service Oriented Architecture.

My own understanding of the "service" concept can be traced back to a number of things I was doing in the 1990s, including enterprise modelling for open distributed processing (ODP), as well as early structured methods for component-based development (CBDI or CBSE). From this perspective, it wasn't hard for me to see that the service concept represented a significant departure from the software paradigms I had learned at university (everything from SIMULA to PROLOG).

By the late 1990s, the software vendors were pushing component-based development. It was already obvious to some of us that the most important thing about a component was not the internal mechanism (its implementation) but the service it delivered. I started attending meetings of the CBDI Forum, and writing for the CBDI Journal. My main focus however was not software but business - developing a business modelling approach that would link component-based software with component-based business transformation. I developed a component methodology called SCIPIO, and in 2001 I published a book on the Component-Based Business, which tried to explain business architecture in terms of business components - coherent chunks of business capability, interacting through service relationships.

But although my friends at CBDI Forum understood this, we found that a lot of people in the software industry still saw components merely as reusable lumps of software - a rehash of modular programming or object-oriented programming. What was often missing from this story was any sense of architecture. However, even at that time, a few methodologies did take architecture seriously: there were some good ideas (including explicit recognition of the service concept) in Select Perspective, for example.

By the early 2000s, people had started to talk about service-orientation and service-oriented architecture. Gradually the large software vendors got their hands on these concepts, and started to sell products and platforms into a growing market called "SOA". Lots of people started to equate SOA with these products and platforms. Meanwhile, some SOA evangelists started to make sweeping (and usually ungrounded) promises about business agility and transformation. A gap started to emerge between expectation and reality.

Some of us had experienced something similar before. In the 1980s, we had worked with Information Engineering and CASE tools, which were sold on the promise of transforming IT productivity. However, achieving these outcomes generally depended very little on the features of the technology and much more on how the technology was implemented, used and managed. I developed a technology change management roadmap, which JMA (and later Texas Instruments) used for planning the adoption of its methodology and technology into some of its larger customers.

So many years later, CBDI developed an SOA Roadmap, along similar lines, in order to help large customers adopt and exploit SOA. And in 2006, I joined CBDI as a full-time employee. One of my tasks was to help turn a considerable body of knowledge (as published over many years in the CBDI Journal) into a well-structured methodology (known as SAE - Service Architecture and Engineering).

Although my instinctive sympathies were always with the evangelists who talked about what kind of future business transformations might be possible by extrapolating the available technologies, I started to get impatient with their inability to talk concretely about business change. At the other extreme, I was underwhelmed by some of the rather narrow and uninteresting uses to which SOA technologies were sometimes being put. Regular readers of this blog will have seen me writing frequently on these subjects.

One source of growing complexity, however, is that SOA can no longer be regarded (if it ever was) as an isolated discipline. On the one hand, it tends to be combined with all sorts of other technologies and practices, including BPM, Business Intelligence, Event Processing (Complex or Otherwise), Grid, Cloud, and anything 2.o. On the other hand, it tends to be allied (sometimes awkwardly) with other architectural disciplines, notably Enterprise Architecture. And there are usually major business changes going on, such as Merger and Acquisition. Whether you are doing a technology change roadmap or a business case, you probably need to juggle several of these factors. In many situations, SOA is no longer the rising star of technology adoption but merely one of the supporting acts. David Sprott, the founder of the CBDI Forum, now sees service architecture as business as usual (BAU), saying that "the key questions to be answered revolve around the level of standardization, componentization and rationalization in business and IT" (SOA in the Recession, Feb 2009). Some SOA pundits have even suggested that SOA (or at least the label "SOA") is dead. See my post Has SOA gone for a Burton?

I have no doubt that the CBDI Forum will quietly continue applying the concepts and principles of SOA to practical business problems, unbothered by all this hype. I remain more interested in business transformation than in technology for its own sake, but I shall continue to blog here from time to time on SOA and related topics. For other topics relating to systems thinking for innovation and business survival, you may want to subscribe to my Demanding Change blog.

Deconstructing The Grammar of Business

2009-06-18T22:45:00.002+01:00

@JohnIMM (John Owens) trots out a familiar piece of advice about data modelling today.

"Want to know what data entities your business needs? Start with the nouns in the business function names."

Starting with the nouns is a very old procedure. I can remember sitting through courses where the first exercise was to underline the nouns in a textual description of some business process. So when I started teaching data modelling, I decided to make this procedure more interesting. I took an extract from George Orwell's essay on Hop-Picking, and got the students to underline the nouns. Then we worked out what these nouns actually signified. For example, some of them were numbers and units of measure, some of them were instances, and some of them were reifications. (I'll explain shortly what I mean by reification.) Only a minority of the nouns in this passage passed muster as data entities. Another feature of the extract was that it used a lot of relatively unfamiliar terms - few of us had experience measuring things in bushels, for example - and I was able to show how this analytical technique provided a way of getting into the unfamiliar terminology of a new business area. I included this example in my first book, Pragmatic Data Analysis, published in 1984 and long out of print.

One problem with using this procedure in a training class is that it gives a false impression of what modelling is all about. Modelling is not about translating a clear written description into a clear diagrammatic structure; in the real world you don't have George Orwell doing your observation and writing up your interview notes for you.

Now let me come on to the problem of reification. The Zachman camp has started to use this word (in my view incorrectly) as an synonym of realisation - in other words, the translation and transformation of Ideas into Reality. (They can perhaps find some support for this usage in the work of the Arab philosopher ibn Arabi, who talks about entification in apparently this sense.) However, modern philosophers of language use the word "reification" to refer the elevation of abstract ideas (such as qualities) to Thingness. One of the earliest critics of reification was Ockham, who objected to the mediaeval habit of multiplying abstract ideas and reified universals; his principle of simplicity is now known as Ockham's Razor.

In our time, Quine showed how apparently innocent concepts often contained hidden reification, and my own approach to information modelling has been strongly influenced by Quine. For example, I am wary of taking "customer" as a simple concept, and prefer to deconstruct it into a bundle of bits of intentionality and behaviour and other stuff. (See my post on Customer Orientation.) As for business concepts like "competitor" or "prospect", I generally regard these these as reifications resulting from business intelligence.

Reification tends to obscure the construction processes - tempting us to fall into the fallacy of regarding the reifications as if they directly reflected some real world entities. (See my posts on Responding to Uncertainty 1 and 2.) So I like to talk about ratification as a counterbalance to reification - making the construction process explicit.

Of course, John Owens is right insofar as the grammar of the data model should match the grammar of the process model. And of course for service-oriented modelling, the grammar of the capabilities must match that of the core business services. But what is the grammar of the business itself? Merely going along with the existing nouns and verbs may leave us short of discovering the deep structural patterns.

A Value Proposition for Enterprise Architecture

2009-06-15T15:30:00.004+01:00

#EAC2009 Something else I took away from Sally Bean’s and Peter Haine’s workshop Reflecting on EA at EAC 2009 was the relationship between two sets of questions.

What is EA all about, what is the (emerging, changing) identity of EA?
What is the value proposition for EA?

I personally find the second of these two questions much more important and interesting than the first. Questions of identity often result in entrenched positions, and (as I discussed in my previous post Think Globally, Act Locally) can produce division between different views. In the case of Enterprise Architecture, there is a traditional view (EA-as-IT-planning) and an emerging view (EA-as-business-strategy).

I think the question about the value proposition opens up a much more interesting discussion about the possible evolution and potential multi-tasking of enterprise architecture teams.

(EA itself needs to understand its business model to help it survive. The full exploration of the value proposition needs something like the Osterwalder business model canvas we discussed in our workshop on on Business Modelling for Business Improvement, so I'll have a go at that. See below for Osterwalder template.)

One of the key questions for the value proposition is the timescale. Sometimes enterprise architecture is described in terms of longer-term value: through-life coordination and capability management. Some people are still comfortable with this; but other people see a difficulty with the fact that business needs to wait so long to realise this kind of value, or even to measure it properly. In contrast, there is growing support for a much shorter-term delivery of value.

Essentially, that means EA must deliver value within same timescale as projects. And what is the nature of this value? Roger Sessions points to the massive failure rate in IT projects, and argues that's something EA can and should be fixing. In other words, the EA value proposition can be defined in terms of improving IT project success ratios.

I see two difficulties with this. The first is one of perspective. If EA is working closely with the projects, then how is the EA perspective any different from project perspective? And if the problem is that projects are doing things wrong, then how can EA fix the problem from within the project perspective? The EA view of business requirements is hardly going to be very different from that of the good business analyst on the project. If EA is no longer taking the long view, then its value proposition is largely based on the hypothesis that the architects may have a bit more knowledge and experience than the business analysts, and some slightly superior tools and techniques. But we might achieve this outcome more efficiently and effectively by simply upgrading the business analysis practice and redeploying the architects as senior business analysts. Indeed, some IT organizations seem to be moving in this direction, although they haven't taken away the formal job titles yet.

The second difficulty is that the job of overseeing projects and ensuring project success is hugely duplicated. Within a large IT organization, we might have project management, programme management, IT governance, tools and methods, quality management (control and/or assurance) as well as enterprise architecture, each with its own "body of knowledge", each trying to prevent projects from getting things wrong (and claim the credit). The word "silo" springs to mind here. (All of those roles might possibly be held by the same person, but does that remove the complexity?)

From a systems-thinking perspective, this looks completely crazy. If the value proposition for EA is simply to correct things that projects are doing wrong, then this counts as "failure demand". If the value proposition for EA is to make sure that projects are successful, then that's putting the responsibility in the wrong place. It is the project's job to be outstandingly successful. If they can achieve this unaided, this appears to make EA redundant.

In summary, I'm not convinced that the traditional value proposition for enterprise architecture is convincing to its customers, whoever they are. (Who are the customers anyway, the CIO or CFO who have to pay for it, or the business line management and IT project managers who are being asked to spend time and effort on EA "for their own good", and are not always grateful for EA attention?) I think the top priority for the enterprise architecture discipline is to find and formulate a viable and meaningful value proposition. And it really doesn't matter whether we call it "enterprise architecture" or not.

Thanks to several Twitter friends for today's discussion: A Jangbrand, Anders Østergaard, Andrew Townley, Brenda Michelson, Colin Beverage, Roger Sessions, Todd Biske. (Did I miss anyone?)

Business Model Template

View more OpenOffice presentations from Alexander Osterwalder.

EA: Think Globally, Act Locally

2009-06-12T20:39:00.004+01:00

#eac2009 The IRM Enterprise Architecture conference in London this month continued some of the themes of the Open Group Enterprise Architecture conference in April, and I saw many of the same faces.

One of the main themes was the scope of Enterprise Architecture. Many people argued strongly that EA was not just about IT but about Business, and this came across from Chris Pott's keynote.

Not everyone agreed, however. When Roger Sessions challenged Chris from the floor, putting the case for the continued relevance of IT to the enterprise architect, there was a ripple of assent around the audience.

EA undoubtedly has a credibility problem if it aspires to sort out broader problems of "the business" when it is currently perceived to have had limited success with its original remit - the narrower problems of IT planning.

Roger posted the question on Twitter: "Two enterprise architecture camps: focus on the global vs. focus on the IT. Which are you?" Most of the replies took the side of the global. Nigel Green linked to something he had posted to his blog last year (What is an enterprise architect?) and said "I'm the 'global' if you mean Business Technology a la Forrester ... EA is about biz transformation not just IT". Anders Østergaard Jensen said "EA = S + B + T from which we can infer that EA is global", and Colin Wheeler said "I think Enterprise Architecture is a logical framework in which the business can make rational decisions. Definitely part of the global focus for me".

It was Tom Graves who found a way of reconciling both positions, by quoting Patrick Geddes' slogan Think Global, Act Local. "Global. IT alone is too narrow ... Lack of whole-org EA creates problems for IT. Act local (IT) think global (EA). Apply EA in detail for IT-systems etc, but always remember the global." With most of the others, Tom remains convinced about the importance of the global. "EA is architecture of enterprise, not IT - IT is just an implementation, nothing more - drop the IT-centrism!!".

Roger suggested a compromise. "You can't deliver high value IT unless you know how IT relates to the organization as a whole. The role of enterprise architecture is to bring a holistic perspective to IT." Or perhaps ""The role of EA is to bring a holistic perspective to IT-supported business capability."(miket0181)

There is clearly a wide gap between AS-IS (enterprise architects frustrated within the IT department) and TO-BE (enterprise architects respected across the business). Even if we go along with Chris Potts's line that enterprise architecture is a form of corporate strategy, there's a way to go in most organizations. Nothing wrong with thinking about the future, but some enterprise architects have got a day job as well.

EA Archetypes

2009-06-09T09:33:00.006+01:00

#EAC2009 Following my workshop on Business Modelling for Business Improvement at EAC 2009, I caught the end of Sally Bean’s and Peter Haine’s workshop Reflecting on EA.

An interesting discussion on EA archetypes. We talked about the contrast between EA-as-visionary and EA-as-realist. The EA-as-visionary is an optimist who produces value by creating new opportunities and producing economies of scale and scope; the EA-as-realist earns his/her keep largely by stopping ill-conceived initiatives, saying No to pushy vendors, and producing economies of governance. (In January 2006, I put the case for Realism in a debate on Optimism with Jeff Schneider.)

Roger Sessions mentioned an interesting correlation in the US government space between IT failure and Sarbanes-Oxley-driven "investment" in Enterprise Architecture, suggesting that a mere formal requirement to produce EA deliverables may actually destroy value. (Roger discussed this in his recent editorial on Obama's Information Technology Priority; he is planning to include some graphs in his talk tomorrow afternoon.) This indicates a third archetype: EA-as-formalist, bureaucrats playing Zachman bingo with little vision or practical realism.

And yet there is probably a place for formal rigour, if it can be balanced with vision and realism. It is the formal rigour that confers some authority on the architect to promote either vision or realism or both. So how do we combine the three archetypes: Visionary, Realist, Formalist?

While it would be crazy for me to equate this triad with Lacan’s triad (Imaginary, Real, Symbolic), I think there may be some weak structural parallels. Here are some starting thoughts.

Imaginary - For Lacan, this is about constructing coherent images. The EA-as-visionary must be good at joined-up-thinking, and good at story-telling.

Symbolic - For Lacan, this is about representing the images in some language. The EA-as-formalist must be able to create robust representations.

Real - For Lacan, the Real is what resists representation. The EA-as-realist must understand the limitations of both the vision and the formal models.

I don't know how fruitful this parallel is going to be, so I need to think about it a bit more.