June 2008 Archives
I've just come back from an Enterprise Architecture conference in London, where I was struck by how defensive a lot of the discussions were around the value of architecture. I could sense the frustration of architects who felt either undervalued or ignored by the IT and business colleagues - it reminded me of a bunch of physicists trying to explain how cool superstring theory is.
I know that for many Enterprise Architects it is blindingly obvious why everyone needs a Zachman or a TOGAF, but they are struggling to articulate this value in terms that normal folk (and other IT brethren) can buy into.
The consequence of this lack of buy-in is that most lovingly crafted architectural diktats (sorry, guidelines) are either ditched as being too cumbersome, or blamed for causing cost & time overruns. Commonly both.
On the surface it is difficult to find fault with the key perceived benefits of EA, typically around standardisation and integration. However, there are two main challenges I have found with EA: the Theory and the Practice.
The issue at the theory level is that most EA frameworks promote standardisation as their mantra. However, for quite a few business challenges this can lead to poorer performance due to the inevitable compromises that come with standardisation. When a business need is time critical (measured by time to market or transactional performance) standardisation can slow down the delivery.
Aha! say the architects. If the standards had been there in the first place, the business would have already been working well. And this is where the practice falls down. The sad fact is that most businesses exist in a chaotic state not because they are badly run (not always, anyway), but because of external factors; as Harold MacMillan said, 'Events, dear boy. Events.'
Therefore, there is little chance of coherent standards being put in place initially because the business was almost certainly reacting to events rather than languorously designing and implementing an elegant and logical architecture. Trying to persuade the business to retrofit a revised architecture for no obvious business benefit is easy if you have the sales talent, but then you would probably have been better pitching to Alan Sugar to win the Apprentice.
What seems to be working in the more successful organisations I have visited recently is a tighter engagement by the Enterprise Architecture team both with the business (understanding the specific challenges faced by different business units) and with IT (embedding architects full time into the major projects, having them incentivised to deliver the project successfully AND meet corporate architecture standards). By engaging with all the stakeholders and communicating the merits of EA effectively, architects can deliver more than an ivory tower.
"Architecture is Politics." Mitchell Kapor, Founder of Lotus and Mozilla.
John Moe
As you will see elsewhere on the Alphacourt website, we are running a joint seminar series with IBM titled 'IMPACT Comes To You' (see here). The main theme of these seminars is 'Smart SOA'.
Giving the normal noise and meaningless labels that tend to adorn (re-)launches of products and offerings, I have to say that Smart SOA is certainly not one of the dumbest brand ideas, and even has some special merit, although perhaps not in the way that Big Blue's marketing folk may have envisaged.
First of all though, I need to get one thing off my chest. Applying the tag Smart to software is an oxymoron. Most people's experience of software is the other dictionary meaning of smart: "to be the cause of a sharp, stinging pain, as an irritating application". Remember expert systems with their fuzzy logic? Or Intelligent software that can think for you - HAL 9000 from 2001? Software only does what you it tell it to do, and then you have to be precise in how you say it.
Smart SOA works as a phrase when you consider it more as an application of the old acronym SMART (Specific, Measurable, Achievable, Realistic, Timely) to Service Oriented Architecture. Given the ongoing challenge of IT to deliver genuine and lasting business benefits, it makes sense to at least appear to be trying to add value.
Most people's experience of SOA so far has been either patchy (we wrote a web service and it worked - we'll try another one next year) or frightened (analysts quoting cost of building SOA to be larger than most companies' annual budget). Even though many CIOs see moving to SOA inevitable, most are still challenged to articulate what the business is going to get for its money if they allow their IT people another toy to play with (IT is usually seen as Kevin the teenager - inarticulate, negative, late for everything and getting bored with anything new they buy).
Taking a SMART approach, IT can provide their parents, I mean sponsors, with clear goals and benefits for any investment project, along with a set of metrics to ensure that promises are quantified and understood.
Another way to get SMART is to break down the journey, by phasing in the adoption of new architecture, rather than going for a big bang implementation. I have found that this evolutionary approach is both more acceptable to business as well as being more practical, less risky and therefore more cost-effective.
It is unlikely that many CIOs are going to be given a blank cheque in the current economic climate - we are back to the 'do more with less' attitudes of the early Noughties. So Smart SOA is not about clever software, but about being SMARTer in how we make use of it.
John 'Mensa (Retired)' Moe
