Alignment as a Percentage

Many people perceive value in something called Business-IT alignment, and argue that we should invest in tools and methods that increase this alignment.

Does the word "alignment" actually mean anything concrete, or is it just a vague metaphor, as I suggested in  my previous post Alignment - Science or Pseudoscience? Here's my challenge to the alignment brigade: I'm not interested in "business-IT alignment" unless it can be expressed as a percentage.

Let's imagine we can define a scale from 0% (no alignment whatsoever) to 100% (total alignment). I guess the two extremes would be practically impossible, but 80% would be significantly better than 40%. So we could suppose that any investment that increased alignment from 40% to 80% would be worth considering, if the costs and risks were acceptable.

But at present, we don't have an agreed scale. People sometimes talk as if alignment was some metaphysical goal (like love), rather than a practical manageable outcome. But while I accept the importance of relationships and trust within organizations, I don't see this as part of the concept of alignment.

And I'm not convinced that Business-IT alignment is necessarily a good thing anyway. As I said at a CBDI Forum meeting back in April 2000, 

"There are some organizations where business and IT are perfectly aligned: they are standing side by side, with their heads in the same sand, aligned in a shared sense of complacency. In other organizations, the opposite is true. It is often in the dynamic, progressive organizations where business and IT are furthest apart." [CBDI Journal "Interact", May 2000]

Furthermore, why is "alignment" only a question for IT. @malcolmlowe comments "interesting how no-one measures business-finance alignment as %. It's just part of bus". And what about HR or other support functions?

However if we had a scale I believe it could be a useful management tool, provided that the results were properly interpreted. Given how many CIOs worry about the "alignment" problem, some of them might want to assess and benchmark the alignment percentage from time to time, to see if it is going up or down. As long as it is clearly understood that there are many things that IT needs to be "aligned" with, not just a simplistic notion of "the business".

Alignment - Science or Pseudoscience?

@RSessions claims that "Simplification occurs when the IT partitions align with the business partitions". But what does alignment mean?

Roger defines alignment as "a measure of how well two patterns overlay on top of each other". But this definition only works between two patterns that already occupy the same space.

For example, I think I know what it means to say that the furniture is aligned with the walls of the room, because I can measure this fact with geometrical instruments (ruler, set square), but if someone says that the colour of the furniture is aligned with the sensibilities of the owner, I can only make sense of this as a vague metaphor rather than a precise measurable fact.

The fallacy of astrology does not lie in the detailed analysis of alignments between the planets and stars - which after all occupy the same astronomical space - but in the notion that the movements of the planets against the stars are somehow aligned with the patterns of human affairs on earth. (And the reason this counts as pseudo-science is that the detailed correlation between sky and earth relies on an interpretation by an astrologer.)

When people talk about business-IT alignment, I can only make sense of this as a metaphor. I am not aware of a robust and meaningful formalization that would permit both business and IT to occupy the same geometrical space, and I can't see the point of inventing one.

All we need is a mapping between two patterns occupying different spaces. An alignment is a special kind of mapping within a fixed geometrical space. If we can't define a fixed geometrical space, then I regard the concept of "alignment" is a misleading metaphor, introducing unnecessary complication. I prefer the general concept of mapping to the false metaphor of alignment.

@aleksb6 objects that my position is "true iff two patterns to map. reality is a M2M relationship, so 'alignment' is not a complication, it's a necessity!" He continues "btw, isn't mapping two patterns just another instance of point-to-point thinking? I thought we wanted to discourage that!"

If alignment doesn't make sense between two things, I can't see that it makes any more sense between three or more things. The desired outcome is a set of structure-preserving mappings between as many things as we need to coordinate. That doesn't mean we can or should design each mapping separately. In all but the most trivial situations, however skilfully we decompose a large problem into subproblems, there is always some coordination (juggling) left to do.

Here's the bottom line. If assertions about business-IT alignment are to mean anything at all, then you have to have a way of looking at a lump of business and a lump of IT and say whether they are aligned or not, and if so how much.

Of course, if you believe you have a modelling language that can express both business and IT, then you might think all you have to do to find out if business and IT are aligned is to compare two models. But this turns out to a circular procedure, because the modelling languages are themselves justified by the claim that they promote business-IT alignment, so we cannot use the modelling languages themselves to prove that business-IT alignment has been achieved. There has to be some point of reference outside the modelling languages.

People keep telling me "alignment" is important, but they can only define it as a woolly and subjective metaphor. So if we stop worrying about "alignment", and talk instead about the various multi-dimensional mappings between a complex system of systems and a complex set of business requirements, we can concentrate on what is objectively important.

And leave the concept of "alignment" for the astrologers. All together now ...

When the Moon is in the 7th house and Jupiter aligns with Mars
Then peace will guide the planets and love will steer the stars.

Beyond the Predictive Enterprise

@ebizQ James Taylor says you (or more likely your organization) should be striving to become a predictive enterprise. His definition comes from an old SPSS presentation.

• Derives maximum value from its data assets
• Understands its business by gaining deep insight
• Leverages advanced analytics to predict outcomes
• Turns this knowledge into action to optimize decision making across all areas of its operations

But prediction forms part of an important learning loop. We make predictions in order to take better actions. There is no point making predictions about customer behaviour unless this prediction allows you to create some value for the customer.

Secondly, we take actions with uncertain outcomes, in order to improve our future ability to predict. Received wisdom may tell us that the “best” colour packaging for a given product is blue, but an inquisitive organization will continually experiment with different packaging rather than settle for a “best practice” solution.

Thirdly, intelligent behaviour allows for its own likely effects. For example, if an intelligent organization drops its prices, it has already considered how (and how quickly) competitors might respond. (In contrast, a stupid organization predicts the outcome of a marketing offensive as if they don't expect other players to retaliate.)
 

So instead of predictive, I prefer the term anticipative or anticipatory. Anticipation means not passively predicting the future, but taking action in advance of the future. Robert Rosen defined an anticipatory system as "containing a predictive model of itself and/or its environment, which allows it to change state at an instant in accord with the model's predictions pertaining to a latter instant". Thus anticipatory contains a degree of self-awareness and self-embodiment, which allows proactive and agile action, not merely disinterested forecasting. This is an essential aspect of what I call Organizational Intelligence.

EA maturity models

Following the popularity of SOA maturity models, a number of EA maturity models have started to appear.

However, if the purpose of this kind of exercise is to assess and improve the effectiveness of an Enterprise Architecture program, then I think it's more useful to think of these models as Excellence models rather than Readiness or Maturity models, and to take inspiration not just from the SEI CMMI but also from excellence models such as Baldrige and EFQM.

There are two important points about these excellence models. Firstly, they don't only look at the capabilities but also at the outcomes produced by these capabilities. And secondly, they provide a systematic framework for developing a customized capability model for a particular enterprise. We shouldn't expect people to invest in specific EA capabilities just because some EA guru thinks it's a good idea, or just because lots of other organizations have adopted this as a "best practice", but ultimately because this capability can be demonstrated to produce the desired effects in this particular enterprise. Whereas an immature organization may have to take some of this kind of thing on trust, a mature organization should be striving for EA excellence, which means that every EA activity is tied to results.

Incidentally, when I have talked to people about Adoption and Excellence models in the context of SOA (in my work with the CBDI Forum), I have perceived a little resistance to the word "excellence". Some people seem to interpret it as meaning quality for its own sake. But in Baldrige and EFQM, excellence means value-for-money, doing exactly those things that contribute to the short-term and longer-term goals of the enterprise and its customers. So perhaps we could call it a Cost-Effectiveness model instead.

So I think any EA assessment should include three vital questions. What does EA cost - not just the architects' own time but also the time of developers, users and other stakeholders in participating in EA activities and complying with EA edicts? Secondly, what added-value is EA producing for the enterprise? And thirdly, what is EA doing to monitor and control the answers to these questions?

To get good answers to these questions, we clearly shouldn't just ask the architects; interviews should involve developers, users and other stakeholders: thus we end up with a 360-degree assessment.

Business Rule Concepts

by Ronald G Ross. Third Edition: Getting to the Point of Knowledge. Business Rule Solutions 2009.
ISBN 0-941049-07-8

A copy of this book arrived in the post this week. I don't know who sent it but I assume it's a review copy from the publishers. (In which case, the publishers have chosen not to implement the standard Cover-Note role. Perhaps they have implemented the If-Anyone-Reviews-It-We'll-Probably-See-Something-On-Twitter rule instead.)

As the title indicates, the book provides a detailed account of the concept of Business Rule, and appears to offer some elements of a methodology for doing something or other. My normal procedure for reviewing such books is to apply the Four Causes.

• Final Cause - what's the purpose, for whom
  
• Material Cause - what is the stuff that is being worked on
• Efficient Cause - who does it, and how
  
• Formal Cause - what's the conceptual framework

Most of the book is taken up with a conceptual framework for business rules. What does a business rule look like, and how can different kinds of business rule be classified. So that's the Formal Cause.

Ross argues that just as the human body is composed of bones (structure), muscles (power) and nervous system (control), so business is composed of factual knowledge (structure), processes (power) and business rules (control), expressed as nouns and verbs.

To me, this looks like a huge simplification. For a start, in order for the human body to do anything useful, the muscles need energy. The biological control system doesn't only control the muscles, it also controls the respiration system - delivering stored energy to the muscles. And for a business to be viable, we generally need to pay attention to the adverbs as well as the nouns and verbs. But in order to consider whether Ross's simplification is useful for some purpose, we need to look at the other three causes.

A business rule is supposed to describe the business. This suggests that there is some stuff (let's call it the implicit logic of the business) from which properly constituted rules can be elicited - the Material Cause. Rules are correct and complete if they accurately and fully capture the AS-IS or TO-BE logic of the business. (Ross tells us little about verification and validation, except to say that it's easier if the rules are held in some kind of repository.)

But which logic? Ross doesn't want to get sucked into expert systems or artificial intelligence (p 23). He argues that the point of establishing business rules is to give you more time for strategic and tactical thinking, problem solving and other stuff (pp 4-5). I infer from this that he is not trying to elicit the logic of these higher-level activities (where my interest in Organizational Intelligence is focused): his methodology concentrates on what he calls Operational Decisions.

The book also contains a number of rules about rules. For example

• A rule saying there shall be no rule restricting the age at which a customer can open an account (p 92). This kind of rule is important in any organization where different units can define some of their own rules.
  
• A rule saying that the cheapest rule should be executed first (p 128). This kind of rule is important for balancing the internal efficiency of a system with the external customer experience, and assumes we have some way of associating different kinds of cost with a rule. (The cheapest rule from the programmer's point of view may be very expensive in terms of customer satisfaction and lost business.)
  

These rules-about-rules are not formalized, and so I'm presuming they are not within the scope of the business rules methodology. However, some important rules-about-rules are stated in the Business Rules Manifesto (p 143-144). For example

6.3 - A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action. 

6.4 - Rules are based on truth values. How a rule's truth value is determined or maintained is hidden from users.

I suspect that these two rules conflict with each another. Unfortunately, I can't verify this suspicion, because the vocabulary used to express these business rules is not coordinated (see p 108). Perhaps Mr Ross should eat his own fish-fingers.

Now let's look at the Efficient Cause. The book seems to be aimed at a business analyst trying to specify the requirements for a system - either a completely automated system or what Ross calls a Really Smart System, which may include people making smart operational decisions with the support of rules that are rendered as guidance messages. However, I didn't get a very clear picture of how Business Rules might fit into a normal systems development methodology. Indeed, the back cover blurb advertises "a common-sense approach to solving today's operational business problems", but I could find nothing in the book that looked like a real business problem (as opposed to fairly routine business requirements.)

(To be fair, I should say that Ross's separation between facts, processes and rules seems consistent with some of the business modelling ideas I have published through the CBDI Forum, so I'm not saying it's wrong, merely that it may not be the whole story.)

Last but not least, the Final Cause. What is the value of this methodology, to whom? Ross asserts that the explicit separation of factual knowledge, processes and business rules produces more effective solutions, and therefore more successful (effective, adaptive) business behaviour (p 5). His approach has the "potential for closing the requirements gap between business people and IT" (p 28). And he asserts that for some class of crucial everyday decisions "you can capture all the business rules and make precise or optimal decisions" (p 31).

Ross doesn't provide any evidence for these assertions, but he doesn't have to, because they are "proven". Humph.

So where does that four-cause analysis leave us? What Ross gives us is a lot of detailed discussion about business rules and how they can be analysed. If you are already sold on the concept of business rules, and possibly interested in using business rules to design a layer of capability services that are decoupled from the entity layer and the process layer, then you may find the book very helpful.

---

Why have I devoted a long blogpost to discussing this book? Because I think it's important for design methodologies to be presented in a balanced way - covering all four causes.. Ross's book is typical of many such books - fairly sound on the Formal Cause, not so strong on the other three causes - and I think this imbalance helps to explain the patchy adoption of such methodologies.