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.

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.

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.

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.

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.

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.

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

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).

I my last post I said that the cause of the misalignment between business and IT is not caused by different pace of change. IT can change as quickly as the business – but it doesn’t. This post lists some of the reasons for this.

Solution: The business must keep IT in the loop. The earlier in the process the better.

Reason 2: Poor solution development methodology.
Many IT Departments are ignoring modern best practice and continue to use outdated waterfall methodologies or work on multi-year projects. It doesn’t work. And history tells us it’s never worked. And I’m not talking software development specifically. The same applies to any IT project (e.g. implementing a new content management system).

Solution: It’s time for IT to get with the times. Develop interactively. Deliver early. Deliver often.

Reason 3: Trying to predict the future.
If you can predict the future I suggest you channel your talents toward pursuits other than trying to predict future business requirements. Most business will prefer to get something functional today than wait for something with bells and whistles. Don’t over-egg the pudding. If you can’t trace the work you’re doing right now to a business requirement then stop doing it.

Solution: Adopt the YAGNI principle. Learn to say “you aint gonna need it”.

Reason 4: Short-sighted views.
Some fall into the exact opposite trap of Reason 3 and build for the ‘here and now’ but don’t even consider what may be needed tomorrow. You need to find a balance. Some changes are easy to predict – factor them into the design.

Solution: Do things today in ways that doesn’t close any doors that may need opening tomorrow. Build extensible and easily maintainable solutions.

A recent comment on this blog got me thinking. The essence of E.A. Anon’s argument was that the misalignment between business and IT is caused by the business changing quicker than IT. But is this really the case?

But does the business really change quicker than IT? I’m not convinced. Let’s consider strategic and tactical changes separately.

Major strategic changes take time. Think about due diligence and legal issues, developing the business case, securing finance, market research, developing new business processes, possibly re-branding the company and launching advertising campaigns, re-organising the supply chain, developing new products and services, staff training and recruitment. And the list goes on. All of this isn’t going to happen over night. All things being equal, I don’t believe there’s an IT Department out there that couldn’t deliver a functioning solution to support the new business in the time it takes the business itself to organise itself.

Tactical changes on the other hand are implemented by the business far quicker – because the size of the change is smaller. Tactical changes are evolutionary (e.g. mail order company creating an online shop). However, if the change requires little change in the business, then it probably requires little change in IT. Of course it takes longer for IT to build an online shop than it takes for the business to say “we want an online shop”, but with the available technology you could probably deliver a solution in next to no time.

If this sounds naïve then I assure you – the cause of the misalignment between business and IT is not caused by different pace of change. IT can change as quickly as the business. So why doesn’t it?

Over the next few posts I will cover what I think are the main reasons for business-IT misalignment. And what to do about it.

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.

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.