From Sedimented Principles to Enabling Prejudices

I have often asserted (on this blog and elsewhere) that principles are over-rated as a driver for intelligent action. However, that doesn't mean principles are completely worthless. In this post, I wish to explore some of the ways in which principles may have some limited use within enterprise architecture.

I am going to identify four rough categories of principle. There may be other categories, and the categories may overlap.

1. Universal Truths
2. Governance
3. Style Preferences
4. Enabling Prejudices

This is a long post, and I think the final category is the most interesting one, so if you are short of time, please read that one first.

---

Universal truths. This kind of principle is something one has to accept and believe, because the evidence in its support is overwhelming. For example, all computers of a given construction must obey certain logical principles, as rigorously proven by Gödel, Turing, Church, von Neumann, and others.

(There aren't many universal truths in the enterprise architecture domain, and the word "proven" is widely abused to mean "something that everyone believes" or "something that nobody has convincingly disproved" or "something that is vaguely associated with a bit of maths or science". I'm not impressed by "proofs" that haven't been published anywhere, are based on wishful thinking and received wisdom, or turn out to prove something fairly trivial.)


Governance. An enterprise or ecosystem may be regulated by governing principles, which are essentially high level rules or policies controlling the structure and behaviour, and constraining certain classes of decision. For example, an enterprise software architecture may be based on certain global principles about accessibility or security, which ultimately link to some specific outcome.

Some EA frameworks arrange principles, policies and rules into a pseudo-hierarchy, but the dividing line between principles and policies can be pretty arbitrary.

Governing principles may be reinforced by standards, but usually the principle is broader than simply conforming to the standard. For example, a principle of accessibility may reference various accessibility standards, but software designers may be expected to strive for enhanced accessibility beyond the minimum standards.


Style. An enterprise or ecosystem may have some stylistic preferences. For example, applications within the Apple ecosystem tend to have a predictable look and feel. In some areas, these stylistic preferences may be elevated to the status of principles.

Some people think that all systems within an enterprise or ecosystem should have a common look and feel. This is a bit like insisting that all the rooms in your house should be painted the same colour, from the kitchen to the bedrooms. Feng Shui practitioners preach the opposite idea; they say that a building should have different zones, with different "look and feel". They then have some complicated rules associating different colours with different compass points, which we don't need to go into here.

In some cases, there are strong reasons for making systems look and feel different. When a pilot is flying a plane, it's probably not a good idea for the flight controls to operate in the same way as the accounting system she uses on the ground for submitting her expenses. A system may even have a different look and feel according to context, thus a database operator may be presented with a different interface when working with the live database, forcing her to slow down and consider every action twice.

In other areas, differences between systems are annoying and may increase levels of error. On Apple computers, and inside some applications, command-D means Duplicate. On Windows, command-D means Delete. I'm sure I'm not the only one who gets these mixed up, and I am grateful that the Windows command at least has a Confirm/Cancel step. In some other systems, the Delete function wipes the file immediately, which is tough if you're used to a Confirm/Cancel/Restore. Other stylistic differences may make navigation harder. For example, regular users of Microsoft Office may detect some minor style differences between the different applications. Just because you've used a particular function in Word doesn't mean you can find it in Excel or Powerpoint. Perhaps it's there, but hidden under a different name in a different submenu. Of course, Microsoft has cleaned up many of these style differences over the years, but perhaps inevitably some remain.

Style often originates with arbitrary choices or one person's aesthetic preferences. Someone once thought it would be a good idea to have X for cut and V for paste, but it could equally have been two other letters. But nowadays users are so accustomed to X and V for cut and paste, that it would be perverse for a designer to use any other letters.

Overarching stylistic rules and guidelines may be presented as local principles, valid for a particular suite of applications. They represent a set of often originally arbitrary choices and preferences, which have been adopted by or imposed onto a community of designers.

I see a subtle difference between style principles and governance principles, and one clue is the nature of the argument that emerges when people don't want to follow them. Style arguments tend to be presented in aesthetic terms - the old design is old-fashioned, younger users want something cool, etc, etc. Governance arguments are presented in terms of outcomes - this would not produce the outcomes we want, or has some other side-effect.


Finally, I get to what is possibly the most controversial one.

Enabling Prejudices. One of the key insights of the early work on Design Thinking (Bryan Lawson, Peter Rowe) was the importance of heuristics, or what Rowe (following Gadamer) calls enabling prejudices, which will hopefully get us to a good-enough solution more quickly. 

As Christopher Alexander notes:

At the moment when a person is faced with an act of design, he does not have time to think about it from scratch. The Timeless Way of Building p 204

We always approach a problem with a set of prejudices or prejudgements. Depending on the situation, these may either help us to solve the problem more quickly (enabling), or may lead us astray (disabling). The acid test of a set of heuristics or design principles is that they are mostly enabling most of the time.

Perhaps one important difference between education and training is that good education encourages the students to think more deeply, whereas good training teaches students to solve problems more quickly. (Or reliably or effectively, or some other adverb.) Thus training initiates and indoctrinates the students into a set of enabling prejudices, which will give them greater practical power.

Inexperienced practitioners may rely heavily on the principles they were taught in training, or have learned from books. As practitioners gain experience, their prejudices may become more refined, more personalized, and more deeply embedded. A lot of the principles articulated for enterprise architecture reflect this kind of enabling prejudice.

Obviously there is nothing wrong with an enabling prejudice when it is correct. A basketball coach might have a reasonable expectation that tall people are generally better at basketball than short people. But in an ideal world, a good basketball coach would be open-minded enough to notice a shorter player who is exceptionally good. It would be doubly stupid to impose a minimum height rule, firstly because you might exclude a really good player, and secondly because you will never get any feedback to tell you to revise the rule.

Now here's the twist. Many enterprise architecture frameworks suggest that practitioners should agree a common set of principles. But here's a contrary thought. Maybe a healthy enterprise or ecosystem encourages diversity of prejudice. (The shorter guy only needs one basketball coach to spot his talent and potential.) If we all have different approaches to problem-solving, then we are collectively more likely to find good solutions to difficult problems, and more likely to spot possible pitfalls. The value of diversity applies both when we are collaborating and when we are competing. Whereas a community with a single (attenuated) set of enabling prejudices would lack resilience, forming a dangerous form of intellectual monoculture.


Some might complain that allowing heuristic variation introduces fragmentation, inconsistency and incoherence into the enterprise or ecosystem, but I think that's incorrect. As I see it, maintaining integrity and consistency is the job of the governance and style principles. The heuristics (enabling prejudices) perform an entirely different job, and I think it is wrong to try standardizing and enforcing them in the same way as the other principles.

---

Christopher Alexander, The Timeless Way of Building (New York: Oxford University Press, 1979)

Dan Klyn, Skirmishing With Ill-Defined and Wicked Problems (TUG, 5 July 2013) - review of Rowe

Bryan Lawson, How Designers Think (1980, 4th edition 2005)

Peter Rowe, Design Thinking (MIT Press 1987)

Stanford Encyclopedia of Philosophy: Gadamer and the Positivity of Prejudice


Related posts: What's wrong with principles (Feb 2010), What's wrong with principles 2 (July 2010), The Power of Principles - Not (Jan 2011),  From Enabling Prejudices to Sedimented Principles (March 2013)

Updated 11 November 2018

Evolving the Enterprise Architecture Body of Knowledge

#entarch #EABOK There is a considerable "body of knowledge" in the enterprise architecture world. Among other things, this includes

• Founding documents that everyone references, such as Zachman's 1987 paper for the IBM Systems Journal, and the MIT book on Enterprise Architecture as Strategy.

• Various summaries and guides to the body of knowledge. Mitre produced a guide to the (evolving) EA body of knowledge around 2004 (known as EABOK), and there is a bunch of people currently trying to produce a new version of the EABOK. The BCS has published a Reference Model for Enterprise and Solution Architecture, which it uses as the basis for its architecture certification.

• Some standards, such as ISO/IEC 42010 and RM/ODP.

• Various frameworks that package this knowledge into some kind of semi-formal structure, such as TOGAF and DODAF/MODAF, as well as the Zachman framework. The Federal EA framework is incorporated into US law via the Clinger-Cohen Act.

• Various tools that encapsulate portions of this knowledge.

• Some attempts to formalize and ground this knowledge. There is some interesting work in the defence community to produce an EA ontology (MODEM) to replace the existing MODAF/DODAF metamodel. Meanwhile, there is a growing academic literature, much of it from the Netherlands for some reason.

• Huge amounts of commentary and proposed additions/revision by individual authors and bloggers. There is also a considerable admixture of insight and obfuscation from the large consultancies and analyst firms.

The body of knowledge as a whole can be understood as a set of definitions ("this is what we shall call a business function"), assertions and observations ("loosely coupled structures are more flexible"), instructions/injunctions ("always agree your principles before planning your systems"), and examples (mostly artificial or anecdotal), together with a bunch of rather spurious or irrelevant claims ("this is a mathematically proven technique", "this classification was invented by the ancient Greeks", "this is what everybody means by 'complexity' "). The body of knowledge also relies significantly on some terms that usually remain undefined, such as "alignment".

This body of knowledge as a whole has been subject to a number of criticisms.

• It is incomplete, inconsistent, imprecise, muddled, simplistic.

• It is impractical, fails to deliver value, not fit for purpose (however that purpose may be understood).

• It carries a hidden ideological agenda (which conveniently suits the commercial interests of the large software and IT services companies).

• It lacks a proper base of empirical evidence - much of the knowledge is received wisdom and rehashed fragments from other sources.

• It relies on "subject matter experts", who often have no experience or training in knowledge research and are merely trading their own preconceptions.

In response to these perceived flaws in the collective body of knowledge, many EA practitioners espouse a personal body of knowledge, which is smaller and hopefully more consistent than the conventional/collective body of knowledge. This personal body of knowledge is often presented explicitly as an alternative to the conventional body of knowledge, for example rants against TOGAF or Zachman. However, personal bodies of knowledge are not immune from the same criticisms, and often suffer from methodological syncretism.



How has the collective body of knowledge been developed and validated? Typically a combination of the following

• This is what everybody knows.
• This is what every good architect knows.
• Here's an interesting new idea, so let's bung it in somewhere.
• Our customers like it, so it must be right.
• This bit of TOGAF is obviously rubbish, so let's chuck it away and put something else in its place.

Imre Lakatos said that a research programme can be progressive or degenerative. A progressive research programme is one that enhances the explanatory or predictive power of a body of knowledge. (For example, the development of new medical knowledge is progressive if and only if it clearly contributes to more effective healthcare.) A degenerative research programme is one that merely adjusts the body of knowledge to explain away inconvenient results. (Hubert Dreyfus has argued that AI was a degenerative research programme, because it ran into unexpected problems it could not solve.) I have frequently observed that much of EA looks more like mediaeval scholasticism (taxonomy for the sake of taxonomy) than modern science.

I know that some of the readers of this blog aspire to push forward the EA body of knowledge in various ways, including the next version of TOGAF and the replacement EABOK - so my challenge to you guys is this: How are you making sure that your work is progressive and evidence-based?


Further discussion in comments below ...

---

Related posts

Methodological Syncretism (December 2010), Arguing with Mendeleev (March 2013), From Information Architecture to Evidence-Based Practice (April 2013), Towards Next Practice EA (May 2013), Enterprise Architecture as Science (August 2013), What is a Framework (February 2019)

eBook: Towards Next Generation Enterprise Architecture


Links added 2 February 2019

Organizing Business Capabilities

#entarch #bizarch Following a Linked-In discussion on business architecture and capability modelling, I was slightly alarmed to see how many contributions to the discussion were based on an argument from authority: IBM says this, Michael Porter says this, Forrester/Gartner says this.

Obviously these are all clever guys, but does that mean they have all the answers? Someone claimed that IBM's model was based on something called "natural clustering", but I don't know what he thinks that means. The only clustering I've ever seen used in architectural contexts has been artificial, meaning that what you get from clustering depends a lot on what algorithm or mechanism you use, as well as when (at what stage in the process, the level of granularity) you choose to carry it out.

In any case, I am sceptical of generic architectures. If I want a house that is exactly the same as everyone else's house, I don't really need an architect at all - I just need a structural engineer to calculate the strength of the beams and align the plumbing. I don't expect an architect to spend months just giving me a slightly modified copy of something he found in a textbook.

I think the interesting question is how to derive a capability map from the particular behaviours of an organization and the particular intentions of its leadership, rather than just imposing some off-the-shelf business school or vendor nostrum.

So, what kind of capability map do we need to understand the organization of capabilities? Many people think all we need to do is identification and classification - decomposing the enterprise into a set of independent capabilities. Business analysts can then document each capability separately (I sometimes use a capability canvas that is adapted from Osterwalder's business canvas), decide which capabilities are of greatest strategic importance, and produce a plan for business improvement. (The UK MOD practises a methodology called Through-Life Capability Management, and a casual Internet search will identify several large consultancies and systems houses that claim expertise in this area.)

This is all well and good, but it misses what I regard as the critical architectural point - the relationships between capabilities. Business analysts may be happy with capability decomposition, but I think business architects also need a capability dependency diagram, which shows, among other things, how one capability creates or modifies, coordinates or governs other capabilities. Many of the popular capability modelling methods concentrate on modelling the operational capabilities only, but I prefer to produce a model that includes the higher level development and management capabilities.

Fans of Stafford Beer's Viable Systems Model (VSM) will regard the operational capabilities as corresponding to what Beer calls System One, while the higher level capabilities correspond to Systems Two through Five. (For many purposes, I find a simpler three-level schema is enough.)

Another schema for modelling different classes of capability can be found in the draft Systems Engineering Body of Knowledge: Enterprise Systems Engineering Background. This schema is useful in recognizing the distinction between operational capabilities and other classes of capability, but I think it is limited by its strong engineering bias and is probably insufficient for the purposes of business architecture.

Marketing genius Seth Godin once reported a conversation with a publishing executive: "People ask me what the hardest thing is... is it finding authors? I tell them that the two hardest things are hiring great people and watching the cash flow." [The Hardest Thing, April 2006] Things like these are not just hard but critically important to the success of an enterprise - because so many other things are dependent upon them.

It is these dependencies that the business architect must understand - in order to see how improvements in one area may or may not ripple through the rest of the organization, sociotechnically as well as technically. That's why I think capability mapping is more than just engineering.

What is Enterprise Architecture (not again)?

Prelude

Let's start with the tweets.

@RSessions: Enterprise Architecture is a tool, not a solution. 
@Cybersal: I agree EA is not a solution; however I prefer to characterise it as a discipline or a practice. A tool seems too mechanistic. 
@leodesousa: I agree it is a discipline/practice that should be embedded into existing processes like proj mgmt, chg mgmt, stratplan
@richardveryard: If we understand #entarch as a means-to-an-end, then the word "instrument" is better than the word "tool". 
@ironick: How about EA is a process? That's how #GartnerEA defines it. 
@RSessions: A process is reproducible. I know very few (only one, actually) EA methodologies that strive for reproducibility. 
@enectoux: EA is a complete discipline and mindset. It has many frameworkS, processeS, methodS, practiceS, toolS… 
@RSessions: Tool" is really a metaphor. The point is that effective use of EA requires training. Just buying "EA" doesn't buy you anything.
@leodesousa: #entarch is not something you buy rather something that is invested in as an ongoing practice

I'm sorry if I missed anyone, but this kind of debate could go on for ever ...

---

Fugue

So here's my take. There are (at least) five perspectives of what enterprise architecture is.

1. EA as instrument. It's something that is used as a means-to-an-end. (Like a tool, but more general and perhaps less mechanistic than a tool.) It is wielded with such-and-such intentions to produce or maintain such-and-such outcomes. If you don't have these intentions, or you don't believe EA can produce these outcomes, then you shouldn't be doing EA at all.

2. EA as discourse. It is a language (way of talking) that expresses (and focuses attention upon) a particular set of concerns and issues. This is what establishes a certain agenda for EA, and helps to differentiate EA from various other practices (such as programme management or requirements engineering or risk management) which might appear to address much of the same problem space.

3. EA as community (of practice). There is a large number of individuals and organizations that identify themselves as part of this community, including several groups and organizations that claim to represent this community and its interests. In practice, EA can be regarded as the totality of what the EA community does in the name of EA.

4. EA as body of knowledge. Among other things, EA bodies of knowledge include various prescribed processes, but it is important to distinguish between the espoused processes (what the book says you should do) and the processes-in-use (what the community actually practises).

5. EA as trade or profession. Enterprise architecture provides a set of paid-for services to the enterprise, or to senior business managers, or to some other individual and collective stakeholders. (Payment can be in the form of salary or consultancy contract.) The commercial viability of EA and the careers of EA specialists depend on a sustainable demand for these services.


There are significant issues for EA from each of these perspectives, which I talk about in my next post What's Wrong with Enterprise Architecture?

Requisite Collaboration

My blogpost on The Startling Cost of Inefficient Collaboration started from the observation that "too much collaboration can be bad". But how much is too much?

Too Little

Barely Enough

Just Right

More Than Enough

Too Much

We often need to make a judgement about the appropriate quantity and quality of something. Such judgements can be difficult ones, because they need to be sensitive to who, why and where. Even something as basic as the right amount of food will vary between members of the same family and at different times. And there is no simple formula that will tell you whether to spend more time preparing for tomorrow's meeting or to get an early night.


So how much is a good amount of collaboration - just enough but not too much? Obviously this depends on many situational factors including purpose and context. We can talk about requisite collaboration - in other words, the quantity and quality of collaboration that is appropriate for a given situation. And although we should not expect a simple formula, this is nonetheless something we should expect to be able to reason about.


It's also important to remember that the quantity and quality of collaboration is not necessarily under the control of a single stakeholder. People who work in large organizations may be able to initiate some meetings and duck out of others, and may sometimes be able to unplug phones and ignore email (although many people experience guilt or anxiety when they do this), but the actual quantity of collaboration emerges from the interaction with everyone else. The bosses at Lehman Brothers had elaborate routines to prevent ordinary staff talking to them, and some commentators (e.g. @markfidelman What if Peter Drucker Taught Enterprise 2.0?) have suggested this could have contributed to the collapse of the firm, but I'm sure even Lehman bosses couldn't cut themselves off completely from urgent demands from important stakeholders.


So Lehman bosses may sometimes have had more communication with other people than they felt they wanted at the time, but with hindsight even they might admit that they didn't have enough of the right kind of communication. Such a judgement is always relative to a particular stakeholder position - other people such as junior staff or minor customers might complain that Lehman bosses didn't listen to them, but to put this complaint in terms of requisite collaboration would be to imply that Lehman bosses didn't do enough listening to serve their own interests and the interests of the firm as a whole.

In some domains, there is a body of knowledge that may help us to determine the right level of collaboration. For example, John Gattorna uses the concept of requisite collaboration within enterprise supply chains, suggesting that collaboration makes sense only with those who truly want to collaborate. (See John Gattorna, Supply Chain Collaboration, Supply Chain Digest June 2007. See also review of Dynamic Supply Chain Alignment by Jan Husdal.)

In any case, we need some whole-of-context view to determine the requisite level of collaboration, as my friend @tetradian points out. For Lehman Brothers, inadequate collaboration led to inadequate organizational intelligence, which led to organization failure. The organizational intelligence methodology should help us think about the appropriate collaboration levels of different scenarios by working backwards from the consequences.


Related posts: What are Silos Good for? (June 2010), Organizational Intelligence After Drucker (August 2010) 

Wisdom of Confucius

#entarch My friend @taotwit appeals to a saying of Confucius in relation to enterprise architecture.

What is necessary is to call things by their right names. ... If names be not correct, language is not in accordance with the truth of things. If language be not in accordance with the truth of things, affairs cannot be carried on to success. When affairs cannot be carried on to success, proprieties and harmony will not flourish. When proprieties and harmony do not flourish, punishments will not be properly awarded. When punishments are not properly awarded, the people do not know how to move hand or foot. Therefore a superior man considers it necessary that the names he uses may be spoken appropriately, and also that what he speaks may be carried out appropriately. What the superior man requires, is that in his words there may be nothing incorrect.” [Analects of Confucius]

Many enterprise architects will strongly agree with this thought, and may even wish to apply it to the question of Defining Enterprise Architecture itself. However, we should remember that Confucius was a highly conservative thinker, who believed in a fixed body of knowledge. (His comment about names was apparently provoked by his disapproval of the Duke of Wei, who had usurped his father's title.)

In Daoism, of course, a name can be named, (but) this is not the constant naming. Thus, whatever one may say about the Dao, cannot but fall short of reality [ReligionFacts]. The same is almost certainly true of enterprise archtecture, as well as the most central topics addressed by enterprise architecture practice.

However, I can wholeheartedly agree with Confucius when he said

“To rule a country, there must be reverent attention to business, and sincerity; economy in expenditure, and love for men; and the employment of the people at the proper seasons.”

For country, read enterprise.

Brownfield Requirements Engineering

Some partial and selective notes from the RESG meeting on Brownfield Requirements Engineering, held at BCS headquarters on October 12th 2010. By Richard Veryard.

---

Chairman's Introduction

Ian Alexander opened the meeting by pointing out the gulf between the demands of real engineering projects (95% brownfield) and the body of knowledge about requirements engineering offered by academics and authors (95% greenfield), and sketching some of the characteristic features of brownfield requirements. The importance of this topic is demonstrated by an excellent turnout for this meeting.

Brownfield Systems Engineering

Ian Gallagher of Altran Praxis presented some experience from several large systems projects, both military and civilian. The typical scenario is a major upgrade of existing systems to improve performance and deal with obsolescence; the upgrade may therefore include different types of requirement

• doing new things
• doing old things in new ways
• migrating away from ageing technologies, proprietary systems or restricted technologies (e.g. those subject to export licenses)

The upgrade may be regarded as a single large increment (from AS-IS to TO-BE) but is often managed as a series of smaller increments.

With greenfield engineering, the requirements of the engineering project are pretty much the same as the requirements of the TO-BE system, but brownfield engineering introduces a critical choice: whether to write total requirements for the TO-BE system or to write requirements for the project (or separate increments) based on the difference(s) between AS-IS and TO-BE. IanG expressed a strong preference for the former, but acknowledged that this isn't always acceptable to key stakeholders, especially if the effort would be perceived as excessive. But in any case it's obviously important to be clear what kind of requirements we are talking about.

Beyond the scope of the TO-BE system, there may be a larger system-of-systems context, in which other equally large systems are the subject of equally large brownfield engineering activity. This raises questions of the interoperability of the increments, and the coordination between autonomous brownfield engineering projects, which is another important issue for brownfield requirements engineering.

A key issue is the pressure to reuse and repurpose existing assets. There are three possible reasons for this.

1. Rational economics - genuine cost-saving based on lifetime exploitation of assets
2. Irrational inertia - desire to justify past investment decisions, resistance to change
3. Commercial - vested interests from key stakeholders (such as contractors) to maintain proprietary dependencies

Requirements such as migrating towards more "open" architectures are therefore not only relevant for an immediate brownfield project but also have important implications for the economics of future brownfield projects.

Managing Brownfield Financial Software

Phil Cantor of Smartstream then talked about his past and present experience managing and maintaining software products in the financial sector. (Most of his examples came from previous companies he had worked for.) The requirements of such products don't come exclusively (or even primarily) from the "users" but from a body of knowledge that the package vendor is expected to master. Phil gave the example of an obscure piece of financial calculation that is now only required in the Philippines: users elsewhere in the world may not know about this, but a package that doesn't cater for this requirement will be unacceptable to a global bank.

The package vendor then has to balance a wishlist of enhancement requests and bug reports from hundreds of user organizations, with the practical constraints of maintaining - and hopefully improving the quality of - an existing body of software.

For me, one of the most interesting issues raised by Phil was when he talked about the platform and its requirements. There is an internal platform supporting the user-facing components of the product suite, containing common services and suchlike, and the requirements for this platform cannot be derived purely from the requirements of the package as a whole. Furthermore, the package as a whole serves as a platform for the business processes of the user organizations (Phil's customers), so the same question arises at that level as well. However, this is not particularly a brownfield issue.

Phil also mentioned the challenges of training. From a sociotechnical perspective this is a major brownfield issue, since the performance of the TO-BE system will be affected by the user habits and expectations (e.g. knowing where to find things) carried forward from the AS-IS system. Training is a solution (and often not a very good one) to some set of sociotechnical requirements, and there may be better ways of conveying a new set of habits and expectations to the users and technical staff, but clearly we need to have an understanding of these requirements as well.

Discussion

Lots of further issues came up in the discussion, and I didn't manage to capture half of them. Someone raised the question of scale - what do you do with a brownfield situation with a complex network of interdependent pieces of hardware and software, with the need for upgrades constrained by small budgets and massive complexity. This led to the question of timing - how do you decide whether to upgrade something now or to defer the upgrade until next year. (Nobody actually mentioned the concept of technical debt, but that is clearly relevant here.)


Finally, my memory and notes can be supplemented by a few choice tweets.

@rmonhem much debate over how much to document requirements with significant re-use of existing applications

@rmonhem most difficult challenges have often been posed by cultural, commercial and legal factors.

@jiludvik Bit too much focus on techniques documenting and signing off detailed reqs. This is not specific for brownfield projects!

@jiludvik Phil Cantor's pres has been very entertaining and spot on for brownfield req's eng. I can certainly relate to many challenges he mentioned

A Value Proposition for Enterprise Architecture

#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 Canvas Poster V.1.0 from Alexander Osterwalder

 

See also: Purpose of Enterprise Architecture (January 2012) 

The General and The Particular

In his post What do you need to know to be an IT Architect? Simon Guest (editor of the Microsoft Architecture Journal) identifies some key elements of architectural knowledge: IT Environment, Business / Technology Strategy, Design Skills, Quality Attribute Skills, and Human Dynamics.

I think there are two important clarifications we can make here.

Firstly, Simon's starting point is, rightly, know-how (skills) rather than body-of-knowledge (theory). Nick Malik makes a similar point in his post on Enterprise Architecture Interview Questions: "proven abilities and past experiences, and not book learning".

The distinguishing characteristic of an architect, in my view, is a certain way of paying attention to a certain class of problems and opportunities. (Just as a chess grandmaster has a vast body of knowledge of past games and variations, as well as a complex mental library of patterns, but these are only useful for playing the game of chess.)

Therefore the architect's knowledge (of the organization, of the business) needs to be active knowledge, what Vickers called appreciation.

Secondly, when Simon talks about "the organization", "the business", and so on, these terms can be interpreted in two ways. Does the architect need to know about organizations-in-general, business-in-general? Or does the architect need to know about this particular organization, this particular business?

Ali Arsanjani has characterized this choice as one between two philosophers: Kant versus Hume. Do architects concentrate on some apriori (generalized, enterprise-wide or industry-wide) schema (Kant), or do they remain grounded in the specific local requirements (Hume)?

(Some people refer to this choice as top-down/bottom-up. But I think this terminology is vulnerable to wide misunderstanding, because different people have different orientations - is the business at the top, or is the generic model at the top? See my post What Does Top-Down Mean?)

I believe the best architects are those that can do both - who have both general knowledge/know-how and particular knowledge/know-how, and can make intelligent connections between the general and the particular. In what ways is this bank like any other bank, and what particular things differentiate this bank from other banks?

That's how we train our SOA architects to think.