Models Should Be Self-explanatory

August 1, 2008

A model (any model) should be detailed enough to convey all important information but abstract enough so it conveys only important information. To paraphrase Albert Einstein, models should as simple as possible, but not simpler.

The whole point of developing a model is to help the communication process. If people can’t understand a model then there’s no point in developing it. As an architect, I use UML. I’m comfortable with it and I understand it. Unfortunately, business people aren’t as comfortable with UML as technical folk and there won’t always be a technical person around to explain the model. So models should stand on their own.

While there is nothing wrong with providing accompanying text with a model, you need to be mindful of what you’re writing. Any text accompanying a model should be supplementary in nature not explanatory. This is a subtle, yet important difference.

Providing too much detail in a model will make it more difficult to understand so some supplementary information may be useful. This should include any information that can’t be represented diagrammatically but is important to understanding the model.

However, the text should not be a translation of the model from diagrams into words. If you’re writing too much of this explanatory text, then you need to rethink your model. There is no reason to use UML all the time. So long as your model is easily understood by its intended audience, the notation you use is completely irrelevant.


Consultant’s Recommendations

July 22, 2008

Today, two colleagues and I were discussing a particular recommendations that we were to present to our client. The recommendation was masterpiece – a brilliant amalgamation of extensive experience and industry best practice forged in heated deliberations.

The only problem was: I knew that the client had almost zero chance of being able to implement the recommendation. This begs the question: what exactly do clients expect from consultants?

A consulting engagement is not about showing the client how smart you are. Clients hire consultants to provide expertise to solve problems they can’t solve themselves. However, you must come up with recommendations that the client can actually act on. Impractical recommendations become shelf-ware, and the problems remain unsolved.

Say you hired a fitness consultant to help you lose weight. He could recommend “an extensive 7 day a week cardio and weight training programme supplemented by a strict calorie controlled diet”. Or he could recommend “30 minutes of exercise 4 times a week and replacing high fat foods with low fat substitutes.” Sure, you won’t reach your goal as fast by doing it the second way – but at least you won’t be discouraged from actually trying. And (eventually) you will get results.

The same goes for your clients. Don’t overwhelm them with recommendations that will be put in the “too hard basket”. Provide recommendations that give the client the results they want, in pieces they can digest.


Make Project Teams Successful

July 17, 2008

This is a short follow up to a recent post by Todd Biske.

Enterprise architects have a critical, but often overlooked, function. One of our key responsibilities is to make project teams successful.

In the world of finance there is the concept of unrealised gains (or losses). For example, if your house increases in value then you’re better off – but only on paper. You won’t realise the gains then until you sell your house.

When enterprise architects develop strategies and design solutions – the business benefits of their work aren’t realised until the solutions are built and running in production.

These solutions are built by project teams. We (architects) are relying on project teams to make us successful. So it makes sense for us to do everything possible to help project teams succeed. The best way to help project teams be successful is to get actively involved in the project. Rather than lobbing various artefacts over the fence – eat your own dog food.

If enterprise architects take this view, it will go a long way to solving the two issues Todd touched on in his post:

  • We can start rebuilding some trust. If architects take an active role within the project teams then there is a far greater chance that what is delivered resembles what was promised.
  • Mentoring will take care of itself. Mentoring works best when it’s informal and relaxed. If architects get out of their ivory tower and spend time with project team then the teams will learn from the architects rather than be taught by them.

Enterprise Architecture Defined – In Business Terms

July 15, 2008

Fear not. This post isn’t another attempt in the seemingly endless quest to produce a concise definition of “enterprise architecture”.

Enterprise Architects are a strange breed. I’m not sure there’s another profession where there is such fervent debate about what the profession is and what its practitioners actually do.

I’m not sure there’s any need for such debate. Enterprise architects know what it is – we live it every day – so there’s no real need to define it. So I can only surmise that a definition is needed to explain to people outside the profession what we actually do. And that’s where the problems start.

A business person asks an enterprise architect what he/she does and out comes an explanation that usually involves words like: governance, model, blueprint, design, plan.  Faced with such an abstract definition, a business person will be thinking “That’s great, but what’s the point of all that?”

When I’m asked what enterprise architecture is, I give this 30 word explanation:

Enterprise architecture is really about “IT investment strategy”. The enterprise architect’s core function is to work out ways of getting the greatest return out of the organisations IT investments.

It’s that simple. That’s the end game. Everything else we do is a means toward this end.


Consolidate THEN Integrate

July 14, 2008

SOA is seen by many as a strategic approach to solve the application integration problem.

Organisations need to integrate for one of two reasons. They either want to share data or they want to synchronise data between disparate systems.

Sharing data is a worthwhile pursuit. For example, when we talk about things like ‘single customer view’ we are talking about collating everything we know about a customer from all the systems we have. Having an enterprise-wide view of critical information, rather than an application-centric view, allows for better decision making.

Synchronising data on the other hand is generally a waste of time. The need to synchronise come about because an enterprise has many different systems to do the same job. For example, the sales department might have one CRM system to manage prospects and the customer service department has a different CRM system to manage customers. Now it doesn’t take a Rhodes Scholar to figure out that there will be some overlap between these two systems. So what’s the solution here? The truly ‘strategic’ decision would be to consolidate the two systems into one. Integrating the two systems is a tactical solution. It’s important to remember that just because a plan of action is long-term doesn’t necessarily make it strategic.

As part of any SOA strategy, you should look to consolidate systems first and then integrate whatever is left.

Footnote: SOA folk will know that in order to enable ‘sharing’ you will need some degree of ‘synchronisation’, but in this case synchronisation is an enabler – a means to a worthwhile end – rather than an end in itself.


Do the Hard Stuff First

July 10, 2008

I have an application development background so I’m well aware of the benefits of agile methodologies. It’s hard to argue against the “deliver early, deliver often” approach. However, I often get on my soapbox about blindly following best practice and the agile approach is not without its sins.

When I was at university it was drummed into us that we should do the hard things first. This approach has served me well – and it makes sense. Delivering the most complex part of the system first:

  • allows you to validate your architecture against the ‘worst case scenario’
  • lets you assess the feasibility f the entire project early
  • prevents complex parts of the solution being rushed at the end when the deadline looms
  • it gives you more time to refactor/tune/test your solution
  • it gives users more time to use the beta and provide feedback

Unfortunately, misunderstanding the agile approach leads teams to take the opposite approach. I recently came across a project that was keen to “deliver early”. Nothing wrong with that – except that the team was planning to achieve this by “leaving the hard stuff for later”. The “hard stuff” included critical architecture decisions. This is crazy. The first release of any solution should have limited business scope but must be architecturally sound. Why deliver something that will become “instant legacy”?

So how can you reconcile the need to “deliver early” with the need to “do the hard stuff first”? Luckily the solution is simple: develop a proof of concept before the project begins. Doing R&D during a project is a recipe for disaster. Doing a prototype means that you have a chance to tackle the hard stuff and you can also deliver it early when the actual project starts.


Reasons For IT-Business Misalignment (Part 3)

July 1, 2008

I my last post I listed 4 causes of the misalignment between business and IT. In this post I continue the list.


Reason 5: Implementers have insufficient domain knowledge.
Obviously IT folk need to understand IT – but that’s the bare minimum required to be effective. It’s important to understand the business and industry that you’re operating in. Without sufficient domain knowledge you can’t communicate effectively with the business and this leads to countless problems (e.g. instead of requirements gathering you ‘take orders’)

Solution: IT folk need to learn the business (and industry) they work in.

Reason 6: IT building itself into solutions.
It’s generally accepted that typical IT Department’s spend roughly 80% of their budget on maintenance and 20% on new initiatives. The are many reasons for this but the main one (I think) is that IT Departments build themselves into solutions. In many cases, IT delivers all the features the business wanted but neglect to factor in all the “behind the scenes” things that are needed to operate the solution (e.g. maintenance screens, report writing tools)

Solution: Build complete, end-to-end solutions that don’t require constant hand-holding from IT.

Reason 7: Line of business instead of enterprise focus.
We know that most IT solutions are developed for a particular business unit. This is largely down to organisational factors (e.g. funding models, governance) and the result is a large number of siloed solutions. And here’s the problem. When a new business initiative starts, every department prepares accordingly (e.g. policies, procedures, staff training etc). Part of the preparation involves burying the IT Department in ‘change requests’. Marketing sends their requests, sales sends their, accounts want changes and so on. And of course IT is notified at the last minute – when everything else has been done. IT can never hope to manage this sudden peak in workload.

Solution: Take an enterprise-wide approach to IT solutions. LOB thinking is not sustainable.

So that’s my 7 reasons why IT cannot keep pace with the changing business needs. It’s not caused by a different pace of change (business changing quicker than IT) – the causes are largely due to timing (business getting a head start) and direction (IT going off on tangents).


Follow

Get every new post delivered to your Inbox.