Broaden Your Horizons

June 17, 2008

On every architect’s bookshelf you’ll find a lof of books. Unfortunately the titles of those books are likely to contain words such as: architecture, pattern, model, design and development (to name a few). I find it amazing that everyone talks about “business IT alignment” but many architects bury their noses only in technical books. Technical competence is the bare minimum that is expected of architects. To take the next step you need to broaden your horizons.

Here’s a suggestion – for every TWO technical books (or articles) you read, read ONE book (or article) from one of the following ‘genres’.

Personal Effectiveness and Branding
Time management and efficiency are critical to getting your job done. There is a limit to how much ‘harder’ you can work. Learn to work ‘smarter’. Everyone ‘knows’ how to chair a meeting or make a presentation. But not many know how to do it effectively.

Branding is important. One of the reasons IT folk have trouble interacting with the business is because they look, talk and act like IT folk. You can learn to ‘fit in’ if you make the effort.

Innovation, Entrepreneurship and Leadership
Enterprise architecture should be about these three things. No book can teach you how to be an innovative and inspiring leader or the next billionaire entrepreneur. But you can pick up plenty of tips and ideas on how to think outside the box and get those creative juices flowing.

Sales and Marketing
IT folk are hopeless seem to sell their ideas. If you haven’t learned this by now, here’s a free tip: if you’re an architect and you’re relying on the technical brilliance of your ideas to speak for themselves – find another job because you’ll never be effective in your current one.

Personal Relationships
The trouble with any organisation is that it’s full of those pesky things called “people”. What’s even worse is that these “people” tend not to listen intently to your every word, mindlessly agree and then slavishly obey. Bit of a shame that. While you’re trying to invent some brainwashing device to make everyone see things your way, how about you read the odd book about negotiation, conflict resolution, dealing with difficult clients and ‘winning friends and influencing people.’

This list isn’t definitive – but it’s a start.

Broadening your interests will make you a far more effective enterprise architect. The non-technical side should be half of your job and you need to work on it just as hard as you work on the technical side.


The SOA Camel

April 16, 2008

There’s a well known saying: “a camel is a horse designed by committee.” The saying has been attributed to Sir Alec Issigonis the car designer responsible for the hugely successful Mini. Design was his chief concern – as it is for Enterprise Architects – so it pays to heed his warning.

There are plenty of people with the word “architect” in their job title: information architects, business architects, infrastructure architects, software architects, solution architects and enterprise architects – just to name a few. There is no doubt that each of these people has a unique skills set and speciality. When you’re building something as complex and far reaching as an SOA it pays to consult with everyone you can to make sure you’ve got all the bases covered. In other words, the process of designing your SOA should be inclusive. But there is a fine line between being inclusive (which is good) and designing by committee (which is bad).

When you get a bunch of highly skilled technical folk in a room “groupthink” is definitely not a problem! Each person passionately explains why his area of expertise is the most important issue. The Information Architect says “it must be about the data!” while the Infrastructure Architect says “we must be able to manage this – that’s the most important thing!” If you try and reconcile the disparate view and try to reach a consensus you”re on your way down the “design by committee” path. The resulting design will be needlessly complex – and the whole process will take an excessive amount of time.

So how do you leverage the valuable knowledge of everyone concerned and keep everyone on-side, while actually delivering a design that is more like a thoroughbred racehorse and less like its fellow ungulate – the lumbering camel?

A colleague of mine came up with a brilliant solution to solve this problem. Rather than debate each and every decision he decided to spend some time devising a “Decision Framework”, which is basically a list of criteria for resolving conflicts. He was working in the software design space with senior developers and I’ll use his examples but the same could be done with architecture decisions in a room full of architects.

Criteria 1: Consistency and readability of source code is important so we will standardise on the coding standards used by Microsoft.

This means all arguments on the naming conventions of classes, projects, variables, namespaces and the like are avoided.

Criteria 2: We will use standard libraries from Microsoft”s Enterprise Library.

This means (for example) that all arguments on the “best” way to connect to a database and execute commands will be nipped in the bud. We will do it the way the Enterprise Library does it. We wont roll out own code and we wont download other toolkits or libraries. It will also avoid arguments about exception handling, caching, logging, security and everything else covered in the Enterprise Library.

You’ll note that the criteria in the decision framework are clear and unambiguous. No fuzzy “motherhood” statements which are open to interpretation such as “we shall use best practice”. Also, the criteria are hard to argue against. You can’t argue that “Microsoft is wrong.” You may have a personal preference which contradicts Microsoft but that doesn’t make Microsoft’s idea wrong.

Once you have a decision framework in place you need two things. Firstly, you need to get everyone to agree that the criteria in the framework are sound. This ensures that any decision made with reference to the framework will be well thought out and logical – and cannot be accused of being a “whim” or “personal preference”. Secondly, you need strong leadership to make sure everyone follows the “rules”. When there are opposing views, they are each measured against the decision framework. And the “winning” opinion is the one the most closely resembles the criteria in the framework.

Business Hierarchy of Needs

April 10, 2008

Anyone that has had basic exposure to the field of psychology would be familiar with Maslow’s “Heirachy of Needs”. Businesses have a similar heirachy of needs.

Maslow’s Hierarchy of Needs is often presented as a triangle :

Physiological Needs

A person’s physiological needs include air, food, water, shelter, sleep etc. Physiological needs are the difference between life and death. A business also has physiological needs : they need suppliers to provide raw materials as inputs, workers to process these raw materials and clients to buy the resulting outputs. Without all three the company will eventually die.

Safety Needs

Safety for people means things like security, morality, law and order. From a business point of view ‘safety’ means one of two things :

  • • Being profitable. A business can survive without profits by breaking even year after year but that doesn’t take into account the opportunity cost of the capital tied up in the business. Investors want a return on their investment.
  • • Fulfilling its mission. Despite not earning a profit (or in some cases even making a loss), not for profit organisations can feel ‘safe’ if they fulfil the mission their benefactors (e.g. governments, philanthropists) have entrusted them with

Belonging Needs

For people these include family, friendship, affection and relationships. The parallel in business is obvious : businesses want to build close relationships with their suppliers and customers.

Esteem Needs

Things like achievement, status, reputation are as important to people as they are to businesses. Business want to be the preferred supplier, they want to be seen as an industry leader and they want prestige. Not because they want to feel “warm and fuzzy” inside – but because all of this translates to the bottom line.


Innovation, creativity, adaptability/agility and learning are all self explanatory and relate equally well to individuals and to businesses.

Why is all of this important? Before you write a proposal or pitch an idea to the executives, the VERY LEAST you should do, is to find out where your organisation fits into the hierarchy of needs. For example, if you’re pitching the benefits of SOA don’t try and sell something at the “self-actualisation” level (like agility) if your organisation has major problems at a lower level, for example supply chain problems. If you propose something that will satisfy that physiological need you improve the odds of your proposal being approved.

The Curse of Knowledge

April 8, 2008

The ever increasing need for business-IT alignment is well documented. But surely the prerequisite for such alignment must be an ability for the two groups to communicate effectively. Unfortunately, technically oriented people continue to bamboozle the business folk with their endless jargon, three letter acronyms (TLAs) and other assorted techno-babble. One possible explanation might be the ‘Curse of Knowledge’.

I recently read Made to Stick by Chip and Dan Heath. The book is about how to communicate your ideas more effectively, that is, make your message ‘stick’ in the minds of the people you’re communicating with. When technical people speak to business folk the message usually goes in one ear and out the other – the message rarely ‘sticks’.

The authors propose that the reason for this is something they’ve dubbed ‘The Curse of Knowledge’ which states that:

Once we know something we find it impossible to imagine what it was like not to know it… and it becomes difficult for us to share our knowledge with others, because we can’t readily recreate our listeners’ state of mind.

There’s an interesting experiment that proves this phenomenon exists, devised by Elizabeth Newton. She divided a group of people into two groups “tappers” and “listeners”. The tappers were asked to tap out the rhythm of well known songs (e.g. Happy Birthday) to a listener (by knocking fingers on a table). The listeners had to guess what song was being tapped out. 120 songs were tapped out. The tappers were asked how many songs they thought the listeners would guess. They decided 50%. In actual fact the listeners guessed 3 out of 120 (2.5%). The tappers were dumfounded by the listener’s complete inability to ‘understand’ what was being communicated. The reason for the discrepancy was that the tappers couldn’t imagine what it was like for the listener NOT to have the information they had – the tappers could ‘hear’ the tune in their head as they tapped – but of course the listeners couldn’t hear this – all they heard were the taps in isolation.

If you’re an expert in a given field you know all the ins and outs, all the different perspectives and all the subtle nuances. You know that nothing is black and white. You know that the answer to almost every question is “it depends”. You don’t want to dumb things down for fear of oversimplifying the matter. The end result is that when these experts communicate they want to convey all their knowledge, with perfect accuracy, right up front. But this is a recipe for making sure that the message goes in one ear and out the other.

If you want to know how to overcome the Curse of Knowledge the read the book. It’s an entertaining read and well worth a look!

In the meantime I’ll give away one suggestion.

One way to avoid the Curse of Knowledge is NOT to dumb things down, but rather, give people just enough information to be useful, then a little more, then a little more and so on. For example, if you were explaining how a car engine works to a 10 year old, you might say:

  • The engine mixes air and fuel. The mixture is then ignited and when it explodes it pushes the car along.
  • The mixture is mixed in a metal chamber called a cylinder. Most cars have 4, but some have 6 or 8 and some really high performance cars even have 12.
  • The fuel-air mixture is ignited by a spark created by a spark plug.
  • The exhaust fumes from the ‘explosion’ come out of the exhaust pipe

Individually, none of these points are ‘dumbed down’ – they are all correct at a basic level. It’s just that we build our listener’s knowledge incrementally.

Goal Question Metric (GQM) Model

April 7, 2008

I love metrics. Maybe it’s naïve to think that “numbers don’t lie” but they lie a lot less than hype, speculation and anecdotal evidence. The hard part is deciding what to measure. The “Goal Question Metric” paradigm is one tool that can help us figure that out.

The whole point of enterprise architecture is to “make things better”. But we need to make sure that we make the RIGHT things better and be able to prove that we’ve succeeded. We need to compare the before and after. And this requires metrics. The Goal Question Metric Model is one simple way of making sure that the metrics we collect (and the proof we produce) is closely tied to the business goals.

The GQM Model is a hierarchy with 3 levels: goals, questions and metrics.

In a nutshell the process involves 3 steps:

  • Identify high level (conceptual) goals. Goals identify what we want to accomplish.
  • Operationalise the goal by generating questions that will define the goal in an unambiguous and quantifiable terms. Questions help us understand how to meet our goal.
  • Specify the metrics that need to be collected to answer the questions

From experience I can say that the distinction between ‘question’ and ‘metric’ can be rather blurred. The question seems to be the metric. The point of the exercise is to go through the process – don’t worry so much about wasting time ‘making things fit’ the model.

The first step in the process is to define the goal. A goal is conceptual not quantitative, and is made up of these components:

  • What? the product, process or resource under observation
  • What aspect?: the quality attribute of the object
  • Why?: motivation behind the goal (improve, reduce, minimise, maximise, understand, control)
  • Who?: perspective of the goal (who’s viewpoint)

Here are two examples of well defined goals.

Example 1
To improve the efficiency of customer relations staff in the call centre from the point of view of a the call centre manager.

What? Customer relations
What aspect of customer relations? Efficiency
Why? Improving
Who’s point of view? Call centre manager

Example 2
To improve the performance of the GetCustomer() web service such that service consumers are satisfied.

What? GetCustomer() web service
What aspect of the web service? Performance
Why? Improving
Who’s point of view? Service consumer

Questions help us move from the conceptual level to the operational level. Concepts such as ‘efficiency’ and ‘performance’ are abstract. Questions help people operationalise these abstract concepts.

Following on from the above examples, we could ask the following questions.

Example 1
The questions need to clarify the meaning of ‘improving efficiency’. It could mean any number of things, such as: increasing number of calls answered, reducing average call time, improving customer query resolution rates, increasing cross selling or reducing customer wait times in call queue.

Possible questions:

  • What is the maximum queue waiting time?
  • What sort of variations do we get in maximum queue times?
  • Are the peak periods? When?
  • Is the maximum queuing time increasing, decreasing or remaining the same over time?
  • What maximum queue time has the company committed to in the customer service charter?

From these questions we can see that the manager is looking to:

  • reduce customer queue times
  • reduce the maximum queue time for any one customer and not the average queue time across all customers.
  • minimise the occurrences of queue times exceeding the published wait times in the company’s customer service charter

Example 2
The questions need to clarify the meaning of ‘improving performance’. Improving performance of a web service seems pretty self-explanatory, but it still needs elaboration.

Possible questions:

  • What service level agreements (SLAs) are currently in place?
  • How often do we fail to meet SLAs?
  • What is the average response time for the web service?
  • Does the average response time vary?
  • When are the peak periods?
  • Are some customer’s details slower to retrieve than others?

From these questions we can see that:

  • We are only looking to improve performance ‘just enough’ to meet SLAs. Improving’ performance and STILL failing to meet SLAs won’t achieve the business goal. Conversely we don’t want to continually spend money to endlessly improve performance – eventually there are diminishing returns to the business.
  • We are looking to reduce the number of occurrences of SLA violations. We are not looking to improve the ‘average’ performance. In theory we could improve average performance and still have unacceptably high violation rates.

Metrics help us answer questions. They also allow us to chart our progress towards achieving the conceptual goals. Note that some metrics can be used to answer more than one question. Collecting metrics requires time, money and effort. We want to collect the minimum number of metrics that will answer the questions we are interested in.

Example 1
To answer the questions posed above, we need to collect these metrics (and no more):

  • Total time spent in queue for every call answered.
  • Total time spent in queue for every person that hung up before their call was answered.

Example 2
To answer the questions posed above, we need to collect these metrics (and no more):

  • For each invocation of the service collect: timestamp, response time and customer ID requested.

So there you have it. The GQM method is a simple way of ensuring that whatever statistics we produce to prove that we’ve made things better, are relevant to the business’s goals.

Let’s take the Example 1 and elaborate further.

Let’s say you were to build a solution (e.g. a portal) that made it easier for customer service representatives to answer customer queries. Because the call centre operator can answer questions far quicker, it will reduce ‘average call time’. This will probably have a flow on effect to queue times – if the calls are handled quicker, more people will get through, and queue times will fall. That’s all well and good but if the business is interested in ‘reducing queue times’ don’t give them metrics to prove that your solution ‘reduced average call times’. Prove you solved their problem – don’t make them connect the dots for themselves. It sounds simple – and it is. It just requires a bit of up front thought.