Executive Moves

Before the start of the football season, football journalists have little to write about except transfer speculation - wondering which player might be about to transfer from one overpaid job to another overpaid job. This period is known as the Transfer Window.

The simplest assumption is that a player's talent is completely transferable from one club to another. His individual performance at his new club will be similar to his individual performance at his old club, and this is why he commands a particular market valuation.

Of course it is never as simple as this. An astute manager may spot a player who is performing poorly for his current club, and may be able to acquire such a player cheaply, at a price that doesn't reflect his full potential. A well-known example is the transfer of Thierry Henry from Juventus (where he had a disappointing season playing on the wing) to Arsenal (where he made his name as a world-class footballer).

Conversely, there have been many players who have been transferred at inflated prices, and who have then performed disappointingly for their new club. Any football fan will be able to name examples. The possible reasons for such failures range from personality clashes and team culture, to differences in team strategy and style. A player that is brilliant in one formation may struggle in an unfamiliar formation. (See Wikipedia: Soccer formation.)

Similar considerations may apply when a senior manager moves from one company to another. An executive commands a high salary because of a widespread belief that her skills and experience are easily transferable within the same sector, or even across sectors. Thus if a company has challenges in (say) supply chain, it seems to make sense to poach some supply chain expertise from elsewhere.

This is turn relies on an assumption that supply chain is basically the same everywhere. In business architecture, such assumptions result in enterprise models that abstract away from what makes each company unique, and concentrate on showing what all companies in a given sector have in common. So naturally there will be a box called Supply Chain. (Or Supply Chain Management, or Manage Supply Chain, or whatever your naming standards dictate.)

When an executive move doesn't work out, this often leads to suggestions of personality clashes or company politics. Technocrats love these explanations, because they regard such matters as beyond their understanding or control. But personality clashes and company politics are often symptoms of some deeper (structural) differences. Perhaps the challenges of supply chain innovation (and the creative tension between supply chain and other capabilities) are not the same in all companies; in which case, we should be wary of relying too heavily on enterprise models that make supply chain appear the same everywhere. Obviously business architects are interested in the things that companies have in common, but business architects must also be able to articulate (and help reinforce) those things that make a particular company unique.

In my presentation to the IASA conference in April 2013, I discussed the evident differences between hi-tech companies (Amazon, Apple, Facebook, Google, Microsoft, Oracle), and challenged business architects to explain these differences in structural terms. I have my own ideas about how this can be done, and I am interested to hear other ideas.

Architecting multi sided business 2 from Richard Veryard

---

@wimrampen writes that this post fits well with @jhagel's Strategy Made Simple. "Nothing simple about strategy ;) but @jhagel does great job showing what's really important", adds @wimrampen.

Generalization as Business Strategy

#entarch @BBCRadio4 Just listening to a business story on the radio: the music retailer HMV is now going to be selling clothes from its flagship Oxford Street store. Of course this kind of thing is nothing new - retailers have always tried to diversify, and there are clothes shops in Oxford Street that are trying to sell CDs, while large retail chains that started as grocery stores now sell books, clothing, computers, mobile phones and furniture, as well as financial services.

For many enterprise architects, this kind of diversification strategy seems like a "no-brainer". If you have a robust retail process, together with the assets and infrastructure to support the process, then surely it makes sense to make as much use of the process as you can.

But successful diversification is by no means a "no-brainer" (how I despise that term and its implications), but requires careful consideration and planning. This kind of planning should be meat and drink for enterprise architects, but not if they imagine that the decision follows automatically from some abstract process model.

So what models and techniques would be relevant to support an intelligent diversification strategy? And how comfortable are enterprise architects with using these models and techniques to support business decision-making?

These are questions I've looked at before on this blog (see the generic v specific category) and will certainly look at again. Meanwhile, I'd welcome your ideas.

TOGAF 9 - Enterprise Continuum

The concept of Enterprise Continuum was present in TOGAF 8, but it is a little clearer in TOGAF 9.

What is an Enterprise Continuum? In TOGAF 8, it was defined as "a virtual repository", but this wasn't very clear. In TOGAF 9, it is now defined more explicitly as "a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures". In other words, it is not the repository itself, but a way of classifying the content of the repository.

The relationship between the generic and the specific has always been a critical dimension of architecture, as I've argued on this blog many times (see label: generic v specific). Enterprise Continuum provides a framework for architects to reason about the right level of generality or specificity for a given artefact.

Here are some implications of this framework.

• Progressive Refinement - Many methods assume progression from the generic to the specific, sometimes known as "refinement". But this is not the only possible approach, and is not always the most appropriate. (See my posts on Progressive Design Constraints and Analyzing the Rusty Lawnmower.)
  

• Management of Variation - Capabilities can often be decomposed into highly generic elements and asset-specific elements. (See my example of Green Coffee Beans.) Decoupling these capabilities helps to drive higher levels of cross-process and cross-organizational sharing. With SOA, this can be supported by separate architectural layers. (See my posts on Homogeneous Business Vocabulary and Merging Capability Modelling with Process Modelling.)

• Adaptation and Adaptability - To achieve agility or flexibility, an enterprise or system or solution may need to be under-determined. This is sometimes confused with abstraction. (See my posts on Adaptation and Adaptability.)
  

• Strategic Differentiation - Enterprise architects need to understand the ways in which a given company is similar to any other company in the same industy sector, and what particular things differentiate this company from other companies. (See my posts The General and The Particular and Service Planning.)

But although this is a critical question for architects, it is poorly supported by the prevailing tools and methods, which often reduce the question to simplistic abstraction hierarchies. Let us hope that TOGAF 9 stimulates further development in this area.

Progressive Design Constraints

When I wrote my piece on Post-Before-Processing, I wasn't thinking about how it might apply to the design process. So when I read Saul Caganoff's reply, on Progressive Data Constraints, my first reaction was, well that's interesting but completely different. But when I read Saul's piece again more slowly, I started to see a common pattern between designing an engineering system (using CAD) and designing a response to a complex unstructured set of events (using what first Vickers and then Checkland call an "appreciative system"). 

In both cases, there is a pitfall known as "jumping to conclusions" - seeking premature closure as a result of an inability to tolerate incompleteness, inconsistency or uncertainty. There is a related pitfall of psychological attachment - being unable to abandon or revise one's earlier decisions. One of the most important skills for the business analyst or systems designer is the ability to throw away his/her first attempt and start again, or to make radical revisions to an existing artefact. (I once built an advanced modelling class with a series of exercises designed to give students opportunities to practise this skill. I think classes like this are still pretty rare.)

There are two apparently opposite approaches to design. According to some design methodologies, we are supposed to start with a vague, generic and all-inclusive concept, and gradually add specific detail and refinement until we have something that we can implement. Work-in-progress should always be consistent and horizontally complete - it just lacks vertical completeness. Alternatively, we start with a bunch of conflicting and sometimes incoherent requirements, and try to find a way of satisfying as much of them as possible. Saul's description fits the second of these.

Bringing the topic back to SOA at the end of his post, Saul indicates the relevance of this kind of thinking to SOA design-time governance. Perhaps because of my background in Open Distributed Processing (ODP), I always think of SOA in terms of open distributed systems, whose design is never complete, always open-ended. So design-time governance always spills over into run-time governance, or is it the other way around?

If we take the SOA project seriously, we should be building systems and services that will interoperate with third-party systems and services, using unstructured data and complex events from a broad range of heterogeneous sources, to be reused and repurposed in user contexts we haven't yet thought about. So we have to be prepared for the emergence of "undocumented features" or "anomalies" (or whatever we want to call them) - and these may emerge at any point in the lifecycle.

Of course in mission-critical or safety-critical systems, there are certain categories of system failure that cannot be permitted. And even for non-critical systems, there is a limit to the amount of buggy behaviour that users will tolerate. But we don't achieve an acceptable level of quality in any kind of complex service-oriented systems engineering by pretending we can design and test our way to perfection in a single step.

Analyzing the Rusty Lawnmower

In my previous post on Responding to Uncertainty, I imagined a garden equipment company responding to an event, based on the appearance (via satellite image) of a rusty lawnmower in John's garden. In that post I was addressing a conceptual question about the nature of the event. In this post I want to discuss a more practical question about the structure and formation of an appropriate event processing network for the garden equipment company.

My starting point is the JDL model of information fusion, via Tim Bass, which would indicate the following event flow architecture.

0. Data collection.

Obtain satellite images.

1. Situation Picture/Event Refinement.

Identify and track some objects, provisionally labelling them "garden", "grass" and "rusty lawnmower".

2. Situation Refinement.

By comparing the map references of these objects with John's address, we associate these objects with John. Furthermore, we can look at the history of these objects over an extended series of images, to see how long they've been there. We can also look at John's history, to see how long he has been living at this address and whether he has bought any gardening stuff in recent years. At this point, we may revise the object labels, because we realise that the rusty object could possibly equate to some other item John bought three years ago.

3. Opportunity/Impact Assessment.

Infer John's intentions about gardening, and the possibility of selling him a new lawnmower.

4. Process Refinement.

Monitor how many lawnmowers we have sold on this basis. Ideally, the process refinement should have some basis for monitoring false negatives (where we didn't spot the rusty lawnmower because it was half-hidden behind an overgrown bush) as well as false positives (where the rusty object was actually an expensive item of sculpture).

The original JDL model refers to these stages as "levels", but the Data Fusion website suggests that this creates confusion because "a hierarchy does not exist from a conceptual point of view". (They might possibly be "levels" in the cybernetic sense, similar to how the term was used by Bateson.)

The model is interesting for several reasons.

• The model supposedly reflects a "natural" cognitive process, including both realtime and historical situational processing.
  
• The event flows can converge at each stage: thus we might have many (possibly heterogeneous) sources of data flowing into one situation picture, or many (possibly contradictory) situation pictures flowing into one impact assessment.
  
• Each stage uses different quantities and qualities of knowledge and interpretation.
• Therefore each stage has different degrees of mission sensitivity. An organization may be comfortable (or may have no choice) with using third party services as event sources, and may be willing to share basic situation pictures with its partners, but may regard the impact assessment as highly confidential.

From a system development perspective, we now have two views of the event processing network - a component oriented view (featuring the concept of the rusty lawnmower, together with patterns and rules for recognizing and responding to instances of this concept) and the flow-oriented view (featuring the stages of the data fusion model). Opher Etzion talks about these two views in his post On Flow-Oriented and Component-Oriented Development. But we probably also need a business/mission view, which drives the requirements in the first place.

The garden equipment company probably didn't start the analysis from the concept of a rusty lawnmower. One possibility is that they started from the idea of some highly generic class of events that would prompt sales and marketing activity. This class of events is then decomposed (top-down) to identify a range of detailed events, some of which might be recognized from satellite images. Another possibility is that they worked backwards from the history of successful lawnmower sales, and then analyzed the relevant satellite images to try and identify any patterns that could be statistically correlated (bottom-up) with this sales history.

In both cases, we need to decouple the data from the explanation of the data. Let's say we find a visual pattern that correlates to lawnmower sales. Our hypothesis is that the pattern indicates a rusty lawnmower, but even if our hypothesis turns out to be incorrect the pattern still somehow works! So we don't throw away the pattern, we just have to look for a different explanation.

This is of course how science has always worked. Many important scientific advances have been based on incorrect explanations. Galileo misunderstood how the telescope worked, but that didn't stop him making some important discoveries. Business networks can be very complex, and sometimes we don't fully understand what is going on, but we still need to build systems that respond as intelligently as possible to what is going on. The point is not to construct a universal theory of lawn-mowers, the point is to sell more lawn-mowers.


Thanks to Opher and Tim for private discussion.

Homogeneous Business Vocabulary?

Nick Malik asks whether a common vocabulary is a blessing or curse.

Who benefits from a common vocabulary - whose agenda is it? IT architects tend to like a common vocabulary because it means they can more easily use the same systems and data stores; bureaucrats tend to like a common vocabulary because it means they can impose the same kinds of procedures and performance targets.

Let's look at the bureaucratic agenda first. In the old days, the bus company had passengers, hospitals had patients, prisons had prisoners, and universities had students. Now they are all supposed to be regarded as "customers", and driven by the same things: "choice" and "customer satisfaction". This reframing has had mixed results - perhaps a few beneficial effects in places, but also some damaging or absurd consequences.

• BBC News: Students: Customers or learners?
• Trisha Torrey: Patient as Customer
  

Meanwhile, IT organizations want to deploy similar solutions across a range of business domains. Here are a few examples picked at random.

• Unisys: Customer Loyalty Solution
• Anari Intelligence: Passenger and Customer Profiling (hedging their bets there!)

Meanwhile, IT architects are often lumpers rather than splitters, and so they like to produce information models with a relatively small number of highly generalized objects like PARTY, which mean absolutely nothing to a real business person.

So in some enterprises, and especially in the public sector, the IT architects may be aligned with the central bureaucrats against the line-of-business. Maybe sometimes there really is a good reason for the diversity of business vocabulary, not just idiot managers being obstinate.

With a stratified Service-Oriented Architecture, it becomes possible to get the best of both worlds - building some highly generic services in one layer, which support a range of different specialized and context-specific ontologies in the layer above. So it becomes possible to accommodate a broader range of requirements without imposing a common vocabulary. Of course this raises some complexity issues, which many IT architects would prefer not to have to deal with. For more on these complexity issues, see the Asymmetric Design blog.

Merging Capability Modeling with Process Modeling

Nick Malik asks about the relationship between capability model and process modelling. "If your company is a process oriented one (or becoming a process oriented one), how do you fit in capability modeling? Do these two methods conflict?"

Nick suggests two answers. In this post I want to offer a third answer. But first we have to understand the purpose of each type of modelling.

Nick mentions two purposes for capability modelling - project planning and service design.

• Project Portfolio Alignment - "With capability modeling, you create a hierarchy of the company's capabilities. You then identify the capabilities that best align to corporate strategy, and which one of them need the most work. Focus your work there, and you get a big payoff through focused investment."

• Service Design - "The activities are where you actually perform automation. You connect services to these activities. This is where work is done."

Nick's first answer is that a capability is a top-level chunk of business, while processes are at a lower level. In a later post, Nick says this is how FEA handles capability and process modelling. As Nick acknowledges, FEA actually calls them business areas (or Lines of Business) rather than capabilities. In my 2001 book on the Component-Based Business, I called these things Business Components, and this terminology is still used by IBM in its Component Business Model. I think this is a useful construct, but that's not exactly what I call capability.

Nick's second answer is that a capability corresponds to the objectives of a specific organizational unit. Capabilities are not directly linked to processes; both capabilities and processes use and share atomic-level activities. This is better, but I am uncomfortable with the organizational tie-up.

Meanwhile, the latest version of MODAF does explicitly include "capability" as a first class construct. MODAF includes a hierarchical decomposition of capabilities, and a many-to-many mapping between capabilities and processes (which it calls "operational activities"). This is a lot closer to my notion of capability.

Another way of getting to my notion of capability is to take Nick's second answer and remove all mention of organization units. While the organization structure may give us some important clues about what an organization does and how it does it, I am careful to avoid hard-coding the organization structure into my business models.

So what is the point of modelling capabilities as well as processes? To justify capability modelling, I want to articulate two additional purposes.

• Management of Variation - Capabilities can often be decomposed into highly generic elements and asset-specific elements. (See my example of Green Coffee Beans.) Decoupling these capabilities helps to drive higher levels of cross-process and cross-organizational sharing.

• Viable System Design - A complete system needs to include management capabilities such as planning and coordination as well as operational capabilities. With a capability model, I find it much easier to check for completeness than with a process model.

So I end up with a notion of business capability which maps easily onto business services, supported by information capabilities which may be implemented as software services. This notion allows for a much finer level of granularity than Nick's first answer, but I think it is much more flexible and powerful than Nick's second answer.

The capability defines WHAT the business does; the process defines HOW the business does it (and the organization structure defines WHERE the business does it). So we expect the capability to be more stable than the process; many capabilities should be shareable not only between different processes within a single enterprise, but between multiple enterprises.

This then raises the question of capability modelling techniques - how do we analyse capabilities? We certainly need to map capabilities onto outcomes (as in Nick's second answer) , but we also need to analyse commonalities and variations within and between capabilities, as well as other dependencies between capabilities. In fact the diagram I find most useful, both for planning and for service design, is the capability dependency diagram. MODAF V 1.1 includes a suggested notation for capability dependency diagrams, but I use a slightly different notation.

Sources

• MODAF Version 1.1 (April 2007)
• L. Cherbakov et al, Impact of service orientation at the business level (IBM Systems Journal, 44/4, 2005)
• M. Dodani, The Architecture of Business (JOT 17/4, 2008)
• R. Veryard, Component-Based Business: Plug and Play (Springer, 2001)
• R. Veryard, Capability Dependency (CBDI Journal, May 2007)

Service Planning

Geoffrey Moore, How to Find Your Competitive Advantage (CIO magazine, May 2006).

At Domino’s Pizza, customer delivery is core; at Pizza Hut, it’s context. At Volvo, safety is core; at Ford it is context.

---

I think it is a fairly clear consequence of Moore's thinking that you cannot have a one-size-fits-all approach to service planning. A service portfolio that is right for Domino's Pizza is not going to be right for Pizza Hut.

How does the IT person know whether he's working in a Domino's company or a Pizza Hut company? Moore suggests a set of questions that helps the IT person find out about the company strategy. In terms of a more formal method, I think these questions can be understood in business modelling terms - in particular, mapping the business capabilities to the business goals.

This is the reason why business modelling is important. And why you can't just go to IBM or SAP, and they give you the standard functional decomposition for any generic food services industry.

I do have a problem with the fact that Moore tends to describe these strategies very much in either/or terms. Either you are Volvo or you are Ford. But what if you are both? We have to be able to provide advice to the kind of CIO who is forced to support both Volvo and Ford, with as much common/shared services and infrastructure as possible.

This comes down to a question of scope. If you are doing a service portfolio for Volvo alone, you may be able to base this portfolio on what is deemed core/contextual at Volvo. But if you are trying to do a service portfolio that will span both Volvo and Ford, you have to build in a much greater degree of flexibility, so that what is core at Volvo can be contextual at Ford, and vice versa.

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.

Green Coffee Beans

Here's a little gem from page 26 of the SAP Magazine (November 2005), talking about the Global Business Services (GBS) division of Proctor and Gamble.

To obtain high economies of scale, GBS models the entire process flow but handles only those processes that are not part of the company's core business. For example, procurement of green coffee beans is managed as part of snacks and beverages purchasing, while GBS assumes responsibility for the P2P system and the vendor accounting involved.

As I interpret this, the process is decomposed into asset-specific tasks (those that are specific to green coffee beans) and generic tasks (those that are common across all purchased items).

The purpose of decomposing in this way is quite explicit. There is no stated intention of outsourcing the generic tasks, and there is no suggestion that they are not part of Proctor and Gamble's core competences. But there is a strong economic argument for managing these tasks as shared (reusable) services; and establishing these as shared services allows Proctor and Gamble to strengthen the underlying competences. The basis for this split (despite what it says in the article) is not core/noncore but asset-specific/generic.

To design services with significant levels of sharing (reuse), it is important to separate the asset-specific elements of the service from the generic elements. Asset specificity is a key determinant of service value. But here's the problem. The models that are commonly used within IT for designing component and services are type models. This means that they are already generic, they are at a level of abstraction at which asset specificity is not visible. (You don't see green coffee beans on a type model, you just see PRODUCT. You might happen to know that green coffee beans is a specific instance of PRODUCT. But you cannot use the type model to design a service that is specific to green coffee beans - or even to analyze a possible requirement for such a service.) This argument applies equally to process models or capability models, to the extent that they reference abstract types such as PRODUCT.

Thus although the Proctor and Gamble solution appears intuitively reasonable, it is not the solution that would be produced naturally and unforced by following any of the popular service-oriented design methods. (Of course, if you impose an arbitrary apriori separation of core/noncore on the problem space, you can produce pretty much any result you like, but that's not the point.)

The popular design methods (and tools) are geared for efficient solution of fixed problems, and do not provide a sufficient basis for reasoning about reuse, adaptability, complexity, and all the other things that service-orientation is supposed to bring. Asset-specificity is an important economic aspect of a service, and service engineers need ways of understand this aspect.

---

updated to remove the little symbol between "Proctor" and "Gamble" which caused problems with my XML feed earlier - sorry

Efficiency and Robustness - On Central Planning

The debate between Ian Welsh and Chandler Howell has continued since my previous post on Efficiency and Robustness, and the topic of Central Planning has appeared. In this post, I want to set aside the ideological aspects of central planning and discuss some of the practical aspects.

Central Planning - The Ideology

The question of central planning is widely seen as a political one, but it certainly isn't a simple matter of left and right. There are many right-wing libertarians who reject central planning as equivalent to Stalinism, the worst excesses of the Soviet experiment. (See this article Central Planning is Spontaneous Economic Order whose author complains that the Santa Fe Institute has betrayed the principles of complexity.) And there are left-wing libertarians who are puzzled or aghast at the centralizing tendencies of some of the right-wing authoritarians as well as corporate commercial interests.

Intelligent Design is of course a form of central planning - but executed by a perfect being rather than imperfect humans. (Boston Globe, via Snowdeal.) Robin Wilton asks whether it is possible for an atheist to believe in Intelligent Design. Well, it is certainly possible for atheists to believe in central planning. There are science fiction worlds in which central planning is carried out by a supreme computer, sometimes known as Multivac (or perhaps Spaghetti Monster). Science fiction writers often use technology as an oblique way of discussing serious philosophical and moral questions.

But if we put the politics and religion on one side, there is clearly a great deal of imperfect central planning that goes on within large organizations. We should be able to discuss this in pragmatic terms rather than ideological ones.

Central Planning in Practice

In a comment to Chandler Howell's previous post, Stu Berman advocates "horizontal integration rather than vertical" and rejects central planning. Chandler replies that, "Central Planning is the best analogy I have ever seen for how large corporations are run today. The only difference [with the Soviet Union] is that the corporations have a lot better computing power to manage their logistics." Chandler goes on to describe the fragility of systems (including large organizations) based on central planning, and suggests that H5N1 (aka Bird Flu) could have a more devastating effect than Hurricanes Katrina and Rita.

Chandler goes on to talk about coordination (what the military call C3I) in a crisis management context. "The disaster in Katrina may have started with the levees breaching, but lack of coordination at any level is what kept it going for days."

Discussion of central planning is relevant not just to the destruction of New Orleans, but to its subsequent reconstruction. The popular alternatives to central planning come under a range of labels including clusters (SwampFox) dynamic improvisation (Arnold Kling via OceanStateBlogger), organic growth (MCB) and private initiative (CapitalFreedom). These alternatives certainly don't all come from the same end of the political spectrum.

Advocacy for central planning also comes from various quarters, including Environmental Planning (WHY, WHAT, HOW and FOR WHOM).

In the real world, we are not likely to have either total central planning or total anarchy, but a complicated mixture of the two. To make a productive contribution to this debate, we have to be able to reason intelligently about outcomes (evidence-based policy) rather than ideological principles. (MCB also makes this point.) Furthermore, we have to connect outcomes with a specific context. (Not generic outcomes that would be exactly the same for New Delhi, New Orleans and New York.)

Interoperability

Central Planning is an attempt to produce all decisions from a single directing mind. To this extent that this attempt is successful, it puts the emphasis on endo-interoperability - coordination within the scope of a single plan. In contrast, exo-interoperability involves dynamic collaboration between autonomous agencies, whose plans may be formulated in entirely different terms.

Chander Howell, Surge Protectors (21 September 2005), Surge Protectors Part 2 (25 September 2005)

Ian Welsh, The Economics of a Flu Pandemic II (24 August 2005)

Related posts on Efficiency and Robustness

Architecture and Abstraction

SOA calls upon designers and architects to operate at a higher level of abstraction.

One mode of abstraction commonly associated with information architects is generalization - they are often thought to operate mainly with generalized business objects/processes, such as CUSTOMER and SALES.

But this is actually not where the real architectural challenges lie.

Instead, architects need to reason explicitly about system structure and dynamics - cohesion and coupling, composition and decomposition, change and emergence. They need to understand granularity and stratification as active choices, rather than text-book patterns.

But the generally available architectural practices and modelling notations simply do not support these challenges. How are architects supposed to pay attention to such concerns as coupling and flexibility, when they are working with models that don’t make these concerns visible, and with practices that don’t support reasoning about these concerns?

We are developing tools and techniques to support this reasoning, and the development of architectural knowledge and know-how.