Modelling Complex Classification

Andrea Westerinen (Microsoft) posts some modelling guidelines, and she was told that some people's heads exploded when reading them.

• What makes for a "good" model/ontology
• Continuing "What makes for a "good" model?"

She identifies three fundamental modelling concepts, which she draws from the work of Guarino and Welty.

• Essence - these are properties that are true for all instances of a class and that "define" the semantics of the class, such as the "property" of "being human"
• Identity - properties that determine the equality of instances
• Unity - properties that define where the boundary of an instance is, or distinguish the parts of a "whole"

In my work on information modelling (for example in my 1992 book) I have long emphasized the importance of understanding semantic identity (how does something count as being "the same again") and semantic unity (which I tend to call membership - how does something count as inside or outside).

But I have been critical of the assumption that we always define a class in terms of essential properties. This is known as monothetic classification, and can be contrasted with polythetic classification, which defines a class in terms of characteristic properties. As I teach in my information modelling workshops, many important objects of business attention are not amenable to simple monothetic classification (for example how does a commercial firm decide who counts as a COMPETITOR, how does the police decide who counts as a SUSPECT) and require a more complex logic.

If you are just building transaction-based systems and services, you may be able to fudge these semantic issues. But if you want information services to support business intelligence and decision-support as well as transaction systems, then you have to get the semantics right.

Of course I can see why Guarino, Welty and Westerinen want to insist on monothetic classification (which they call rigidity). But then how can they model the more fluid and fuzzy (and I think more interesting) business requirements?

(Sometimes the practitioners of "ontology" like to think that they are dealing with supremely abstract and generalized stuff, but if they make too many simplifying assumptions of that kind then their ontologies aren't sufficiently generalized after all.)

Architecture or Firefighting?

For many organizations, the main worry today is Business Survival.

ZDNet blogger Ian Finley reckons "companies will need architects when the crisis is over, but today, they need fire fighters". (When the building’s on fire, who calls an architect?)

In response, fellow ZDNet blogger Joe McKendrick said that "the problem is we don’t have enough architecture as it is, and even when times are good, we’re always firefighting". (SOA 2009: Do we need architects or firefighters?) Mike Kavis agrees: "The reason there are so many fires is that there is so little architecture!"

Comparing the IT crisis with the financial crisis, my colleague David Sprott talks about a toxic mess of IT assets that can’t be easily cleared up. As he says, "although we may be cancelling projects and reducing activity, unless we get smart on architecture we are increasing the toxic mess". J.P. Morganthal uses another name for this concept - technology debt.

As far as I can tell from Joe's later post, Ian and Joe have found a middle point of agreement: focus-focus-focus on the essentials. (2009: a year of extreme focus)

These are not the only voices arguing that Little SOA is more practical/pragmatic than Big SOA. See for example Jordan Braunstein.

---

At the bottom of these debates is an important cultural clash. Some organizations have always been strongly focused on delivery - following the JFDI management style. In other organizations, the emphasis has often been on careful planning and inclusive consensus-building.

There are problems with both extremes. As a consultant, I once had the experience of working with two organizations at the opposite ends of this spectrum at the same time - trying to get the first organization to slow down and the second organization to speed up. (As a result of this experience, I came up with a novel approach to working with organizational culture, based on the five elements of ancient Chinese thought. Remind me to tell you about it sometime.)

In many organizations, there are strong cultural divisions within IT - developers versus architects versus project managers. (In previous posts I have used the metaphor of planets: Mars, Venus, Saturn, or Uranus, while of course Enterprise Architects are from Pluto.) The current climate maybe seems to favour the project managers and the developers over the architects. But that doesn't mean that the architects should abandon their principles and expertise, and pretend to be project managers or developers. As if that's what anyone needs.

What architects do need to do is find a new way of engaging with the business and the rest of IT, in a way that achieves a better balance between the different cultures. (If I can find the presentation, it's probably on a floppy disk somewhere, I'll stick it onto my Slideshare account. Update: Elements of Change)

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.

Business Capability Management

Mexican consulting firm TCDS defines Business Capability Management as a holistic management model as follows.

A Business Capability is a comprehensive ability of an organization required for meet customer expectations without exception. If an organization is going to develop sustainable competitive advantages in terms of agile core business capabilities, four strategic business capabilities need to be developed. We called them BCM Metacapabilities:

1- Value Proposition Creation (VPC)
2- Business Capability Development (BCD)
3- Capability Operation Management (COM)
4- Managed Capability Evolution (MCE)

I'm not sure about the detail of their approach, but I like the overall message, in particular the concept of metacapabilities.

What counts as holistic is of course open to debate. One obvious dimension is timescale, as in Through-Life Capability Management (AOF). But there are other dimensions.

TOGAF 9 - Holistic Enterprise Change

One of the advertised features of TOGAF 9 is something called "Holistic Enterprise Change". A quick Internet search for this phrase revealed very few hits, mostly to the TOGAF materials themselves. Here's what the Open Group says (What's New In TOGAF 9).

"TOGAF has a solid history in IT architecture, considering the ways in which IT can support enterprise change. However, as TOGAF has grown in depth and maturity it has become a framework for managing the entire spectrum of change required to transform an enterprise towards a target operating model. TOGAF 9 continues this evolution and incorporates a broader perspective of change that allows enterprise architecture to be used to specify transformation across the business, data, application, and technology domains."

Is that it? What exactly is there in TOGAF 9 that justifies this claim? I don't believe TOGAF 8 was ever fully explicit in excluding these elements, and TOGAF 9 doesn't provide much new detail on these elements.

I've got an idea what it ought to mean, but I am aware that "holistic" is one of those words that people often abuse - perhaps thinking it's just a fancy way of saying "complete" or "comprehensive" or even "alternative".

My understanding of holistic is that it entails some kind of emergence - the whole is greater than the sum of the parts. See Wikipedia on Holism.

In the context of enterprise architecture, this could mean something like this: When you make changes to the business as well as changes to the systems, you may get more than you bargained for. Conversely, when you make changes to the technical systems without making changes to the human systems, you may get less than you bargained for.

Is this perhaps what TOGAF 9 is getting at? If so, does TOGAF 9 have any answers to these fundamental questions?

---

I posted a question about the meaning of holism to two Linked-In groups. There was an excellent discussion on the Enterprise*As*Systems group. On the Enterprise Architecture Network, however, the comments all appeared to assume that "holistic" meant the same as "whole". Having looked at the TOGAF presentations by Walter Stahlecker and others, I have regretfully come to the conclusion that the use of the word "holistic" in TOGAF also reflects this misunderstanding.

I know Wikipedia isn't perfect, but it does contain a reasonable definition of holism, which I had pointed to, so there's no excuse for ignorance.

From Espresso to Instant

Starbucks is changing its business model. Or as CEO Howard Schultz tells the Huffington Post, Staying Real in an Instant. Starbucks will be selling shots of instant coffee, for under a dollar a cup. The UK price is said to be around 60p.

Some people may have thought that "espresso" was the Italian word word for speed. (It isn't - it means "pressed".) So what could be faster than express coffee? Instant coffee!

Of course the word "instant" isn't about getting the coffee more quickly either, it is about doing away with all that fancy machinery, in whose use Starbucks makes such a charade of training its baristas. (A year ago, Schultz ordered all US stores to close for a three-hour training session "as part of an effort to improve coffee quality and revive the chain's flagging fortunes" [Guardian, 26 Feb 2008].)

Shultz now claims to be responding to the increasing mobility of consumers. "Imagine a cup of Starbucks VIA Ready Brew on a mountaintop" he says, as if willing us to imagine millions of Starbucks customers on some remote and implausible trek.

But clearly his real interest is selling mass market coffee. He hopes that the Starbucks instant coffee will be not only better-tasting but also "paradigm-changing" (whatever that means), and hopes "to turn on a whole new set of coffee drinkers to the Starbucks brand". But the obvious risk is that the old set will be turned off. He acknowledges that this move is a gamble (he calls it "a considered bet"), and expects "to learn a lot ... over the coming weeks". You bet.

In what sense does this count as a new business model? Starbucks already sells ground coffee and coffee beans in supermarkets across the USA. Many rival coffee purveyors have already shifted to the Gillette model, in which the coffee machines are sold cheap or practically given away, and you make your money selling overpriced pods of coffee.

The challenge faced by Starbucks is not choosing one business model, but attempting to combine two or three different (and possibly incompatible) business models at the same time. Such composition faces questions of cross-subsidy, brand dilution or erosion. Are there any reliable rules or patterns governing the interoperability (compatibility and composition) of business models?

See also

• Starbucks to Combat Brand Erosion with Loyalty Program (Marketing Vox, March 2008)
• Starbucks: How Growth Destroyed Brand Value (Business Week, July 2008)

Update

• Why Starbucks should become a retail bank (John Gapper, FT, May 2009)
  

SOA and Holism 2

Holism is another one of those much-abused words. Does it mean anything at all for Service-Oriented Architecture?

In a keynote address to ENASE 2008, Tony Shan introduces "a holistic 9-point list of SOA wisdom". What magic can convert a 9-point list into holistic wisdom?

Volker Hoyer (SAP) has developed what he describes as a Holistic analysis framework for Collaborative e-Business Process Modelling.

Rex Lee (Research in Motion) has written a series of posts on Holism and Enterprise 2.0

• Part 1: Introduction to Holism & E2.0
• Part 2: Organizational Complexity
• Part 3: Process Complexity
• Part 4: The Real Opportunity

For Rex, holism gives you "a complete unified end-to-end understanding of your company, products/services, processes and customers". Rex sees complexity as the enemy of holism.

"Complexity ends up destroying our ability to achieve a complete holistic (end-to-end) understanding of the company, the products/services, and its customers. ... The bigger the organization and the larger the hierarchy, the more difficult it is to truly understand the entire business. This lack of holism, eventually results in decisions and ideas that may be good for a small group but is actually not the best option for the larger group."

But this seems to be based on a thoroughly confused notion of holism. What I think Rex is talking about here isn't holism at all, but panorama. A panoramic view is a complete or wide-angled view of a situation, sometimes called "The Big Picture".

Holism is something quite different. Holism addresses the inherent complexity and irreducibility of systems. An holistic view may perceive fractal patterns, with the same structures recurring at many different scales and levels: this certainly seems to be relevant to SOA. An analyst who adopts an holistic approach may perceive a problem in one system as a reflection of a problem in a much larger system. An SOA architect needs to address problems at different levels of abstraction, and to understand how these are all interconnected and integrated.

If the people talking about holism understand this kind of thing, why aren't they talking about it? And why do they use the word "holism" as if it were just a fancy synonym for "whole"?

Broken Business Models 4

Imperative 1: Have a sense of purpose

• It's not a record, it's a movement (FanForce) - (Was that really Dylan? Or was it Arlo Guthrie?)
• Make the world smaller (Seth Godin)
  

Imperative 2: Analyse

• Business Model, Schmizness Model (Peter Rip)
• Business Planning: Building an Effective Business Model (Andrew J. Sherman)
• Is Your Business Model Broken? (C. J. Hayden)
• Is Business Modeling a Lost Art or New Science? (Ventana)
  

Imperative 3: Differentiate (e.g. "Freemium")

• My Favorite Business Model (Fred Wilson)
• In Twitter's Scoble Problem, A Business Model (Om Malik)
• How to create a profitable Freemium startup (spreadsheet model included) (Andrew Chen)
  

Imperative 4: Diversify

• What If Your Business Model Gets Hit By A Bus? (Sahar Sarid)

Imperative 5: Don't Hesitate

• The best time to change your business model is while you still have momentum (Seth Godin)
• What if Your Business Model Changed Every Four Hours? (Jason Burby)
  

Imperative 6: Stay Cool

• Don’t panic when the new business model isn’t as ‘clean’ as the old one (Seth Godin)
• Failure is okay, as long as you don’t spend too much (Kevin Dana of Accenture, via Joe McKendrick)
  

Imperative 7: Infinite Resource and Sagacity

• Sage shows why bigcos can’t be trusted with SaaS (Phil Wainewright)

Hypothetical Business Models

Robin Meehan (Smart421) asks a question about modelling time sequence dependencies in EA modelling tools

"I often want to model ‘what if’ scenarios, i.e. what the various architecture domains would look like if we proceeded with Option A, or B etc ... [but] I don’t want my various different options to ‘bleed’ into each other in the model. ... The only way I’ve found round this in the past is to duplicate parts of my model to keep them separate (in different packages etc) - which is a bit ugly."

Of course, the problem Robin identifies is more than just time sequence dependencies. Sometimes we have to explore the differences between A-followed-by-B and B-followed-by-A, but there may be many other permutations to explore. If you have to duplicate parts of the model for each permutation, this severely limits the number of permutations you can compare.

Many architects will try to solve this kind of problem by abstraction - coming up with a model that abstracts away from the differences between the options, so that the model supports all the possible options and all the possible permutations between the options. However, the standard model isn't then much good for comparing the options. In some cases it may be worth building a flexible capability that can support both A and B, but how do I tell whether this is one of those cases?

(Michael Bell's SOMF modelling approach does allow AS-IS and TO-BE to be shown on a single diagram, but I don't know how practical it is to put multiple alternatives on a single diagram.)

What Robin highlights here is that the standard modelling tools and notations aren't always very helpful at supporting choice, especially when the choices get at all complex. Often it seems that the tools only really work for documenting the architectural and design choices that have already been made, rather than for making the choices in the first place.

The best answer I can give Robin is to use the available tools, but to adopt a different modelling style. But I need a good case study to work on. Contributions welcome ...

Business Model and Financial Viability

A venture capitalist called Fred Wilson goes back to basic economics - When Talking About Business Models, Remember That Profits Equal Revenues Minus Costs. As Phil Wainewright comments "Has the world become so blind to the basics of commerce that it needs reminding of such a basic tenet? Apparently yes."

Fred is certainly not saying that all companies should try to survive on current revenues alone. Clearly there will be many companies that will continue to attract investment based on future projected revenue - that's exactly where the venture capitalist comes in. However, the viability of a start-up company is entirely dependent on the willingness of people to invest their time, energy and money against some future returns.

What Fred is saying is that these returns are ultimately based on profit rather than revenue. Start-up companies can no longer afford to employ large number of people, if that merely results in a slightly better product and slightly higher revenues. What matters to the venture capitalist are such ratios as operating leverage - how much projected revenue per employee.

Leverage rather than size. Bigger isn't necessarily better. In the recent past, many mergers and acquisitions have been justified in terms of financial engineering rather than genuine creation of value. Fred's point is that even organic growth is suspect if it doesn't make the organization more viable. Why on earth does Facebook (for example) need a thousand employees? What value are they actually going to produce?

A few years ago, we had people asking What is the Right Size of a Service? Now I think the industry is ready to ask the next question: What is the Right Size of a Service-Oriented Business? Many organizations oscillate unstably between uncontrolled growth and painful cost-cutting. It would be better to have a more stable approach to questions of size and viability, and the business model needs to help us with these questions: What is the ideal size of a given business, and how can this size be maintained?

---

Update: See Seth Godin on The Right Size

TOGAF 9 - Business-Led SOA

Shall we see SOA as a software engineering challenge or a business opportunity? TOGAF 9 makes a clear and unequivocal statement in favour of the latter, and identifies the following characteristic features of Business-Led SOA.

• Rich domain knowledge of both horizontal, cross-cutting concerns, such as human resources (HR), finance, and procurement alongside vertical, industry-specific concerns

• A structured, quantitative understanding of business value, costs, differentiators, and quality measures

• Broad understanding of current capability, showing both business capability and how it is supported by IT

• Broad understanding of the feasibility and viability of particular SOA technology-driven solutions

This is contrasted with "a technology-centric, developer-led SOA community that maintains a core focus on the similarities across industries, organizations, and products to achieve benefit".

(In other words, an emphasis on standardization, and the one-size-fits-all economics of scale characteristic of the technology-centric approach, are complemented with an emphasis on business capability within a specific business context.)

Enterprise architecture is then positioned as "a set of tools and techniques to link top-down business-led SOA to bottom-up developer-led SOA". Enterprise architecture becomes "a foundation for service-orienting an organization".

(In other words, enterprise architecture is what puts the A into SOA.)

Technology-centric SOA already makes a clear distinction between the specification of a software service (sometimes known as the service contract), and the implementation and deployment of this service. Business-led SOA applies the same principle at the business level: "Defining business services allows an organization to differentiate between business capability, the fulfilment of business capability, and the consumption of business capability".

(In other words, enterprise architecture supports service-orienting the business, not just service-orienting the applications. Service-orienting the business doesn't just involve IT reengineering, and "justifying the cost of IT reengineering against business value", but also business reengineering.)

Is this enough? Is the glass half-full or half-empty? Some commentators are complaining that the business end of TOGAF is still disappointingly thin. But I prefer to see it as a move in the right direction. And I can see some promising openings here for the work we've been doing on alternative business models ...

---

Footnote

Business-led but technology-centric? See my post on Jargon Orienteering.

TOGAF 9

Released this week in San Diego, the long-awaited new version of TOGAF 9 - the Enterprise Architecture framework from the Open Group.

My first question was the extent to which TOGAF 9 addresses some of the SOA issues that have been overshadowing TOGAF 8 for over five years. I was particularly pleased to see the emphasis on Business-Led SOA (section 22.3).

In addition, there are some new or enhanced areas that look exciting.

• Architectural Partitioning- this abstracts away from the specific rows and columns of the Zachman matrix, while retaining the underlying principle of articulating different architectural views and domains in a systematic manner
  

• Business Capability Management - following the lead taken by the architectural frameworks of the defence world (DoDAF and MODAF), but applying a high-level concept of business capability to the civilian world. For example, the TOGAF guide points to the relevance of concept for governments in planning horizontal interoperability and shared services. Excellent.
  

• Content Framework. A generic reference framework for architectural deliverables.
  

• Enterprise Continuum. This concept was already present in TOGAF 8.1, but is now much clearer, for example in the way it talks about the general and the specific.
  

• Holistic Enterprise Change. This is mentioned as one of the benefits of TOGAF 9, but there is (as yet) little substance behind this. Clearly an area for further work.

This is clearly an enormous leap forward from TOGAF 8.1, but I haven't analyzed all the detail yet. Watch this space.

---

Early Commentary

Industry Analysts

• Beth Gold-Bernstein
  
• Sandy Kemsley
• Brenda Michelson

Vendors

• Wayne Horkan (Sun)
• Nick Malik (Microsoft)
• Ron Tolido (CapGemini)
  
• Mike Walker (Microsoft)

Broken Business Models 3

When people say “the business model is broken”, they are not talking about the kind of models you can draw in UML or BPMN or ArchiMate, but about the set of assumptions that enable the business to survive and succeed. What kind of value does this business provide to its stakeholders, and how can this added value be maintained and extended?

Business models of this kind have long been used for complex business planning. A few years ago I built a business case for a complex multifunction smartcard scheme, in which we used a simple simulation tool to work out how many people needed to carry the card, and how many outlets needed to accept the card, within what timescale, in order to make the scheme viable. (The tool allowed us to create sliders to represent some of the key assumptions - we could move each slider and see how it affected the shape of the graph, or the speed that the scheme would reach critical mass.)

Business models like these are essentially quantitative. So how do we bridge between these models to the enterprise models used by Enterprise Architects, which are basically line-and-box structure diagrams? Where do emerging notations like e3value and BMM fit?

---

Amusing footnote from The Onion

Even CEO Can't Figure Out How RadioShack Still In Business
(The Onion, April 23, 2007)

"There must be some sort of business model that enables this company to make money, but I'll be damned if I know what it is," Day said. "You wouldn't think that people still buy enough strobe lights and extension cords to support an entire nationwide chain, but I guess they must, or I wouldn't have this desk to sit behind all day."