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.
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.
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.
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.
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.
June 26, 2008
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?
The word “agility” is getting a lot of press lately, thanks largely to the hype surrounding SOA. IT must be more agile and respond quicker to changing business needs. Or so the story goes.
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.
June 4, 2008
In a recent post Eric Roch touched on the interesting subject of programmer obsolescence. I agree with Eric – I don’t believe that programmers are looking down the barrel of ‘forced obsolescence’. But I do believe that many will become obsolete – by choosing to ignore the seismic shifts in the software development space.
Since I graduated from university not a lot has changed in the software development space. The science of software engineering is pretty much the same as it’s always been. Sure we’ve had a few significant blips (e.g. web based and distributed applications) but even in those cases we had sound engineering principles to fall back on – we just had to apply those age old principles to solve new problems.
Many programmers will scoff at this and say “what do you mean nothing has changed? New languages, SDK’s, tools, technologies and libraries are constantly released and we have to keep up with it all.”
I think they’re missing the point. The process of cutting code has changed – drastically and for the better. We’ve now got excellent tools to help us write code (IDEs, code generators, model driven tools etc). But what hasn’t changed a lot is the science of software engineering.
But software engineering is changing and programmers need to change with it. The seismic shift I’m talking about is:
The move from applications to platforms.
Most programmers today write applications. They’ve done it for years and they’re comfortable with it. Over the years the tools they use have changed but the fundamental software engineering principles haven’t. But that’s about to change.
Programmers will increasingly have to deal with platforms – either developing them or plugging into them. The software engineering principles in this scenario are radically different and you can’t rely on the same principles that served you so well when developing closed, stand alone applications. Extensibility and interoperability is where the world is heading.
The programmers that understand this shift will do fine. Those that don’t will become obsolete.