Open group conference

In these recessionary times, taking short term view and conserving cash is the mantra. However negligence of architectural matters and short term view, actually adds to long term woes and costs. The way you would not stop essential maintenance of critical components, you must keep maintaining your enterprise architecture. Architectural spend prepares your IT organisation for long term survival and efficiency. However winning this argument is not easy.

This week I will be speaking at The Open Group's Enterprise Architecture Practitioner's conference about my experiences on how to navigate architectural transformations through sanctioning processes in these tough times. There is another panel discussion on same subject. If any of the readers are around, I would be happy to meet up in person.

To buy or to build, that is the question.

Buy before build, is the mantra you would hear more often in enterprise IT. Most analysts would support this line and will have manier reports proclaiming the benefits. However a few independant analysts, tend to put a rather balanced perspective on things.

It appears buy or build decisions tend to fluctuate from buy to build and back to buy depending on where the equilibrium has shifted. The market forces make sure no option remains attractive long enough to become a successful mantra for all the time.

Most enterprises manage technology life-cycle thru some sort of adoption models. These parameters must be aopted in such models, to inform the continuos evolution of to-be state of enterprise architecture. Evolution of Cloud Computing (or XaaS) is a disruption that should also be kept in mind, while building these models. As options are no longer just buy or build, but could be buy, build or lease!

I am listing a few parameters I think that are very important. I would love to hear whether readers would like to add or contest any of these.

1. Commoditised capability vs differentiating capability
   Does the system that is sought to be bought, represents differentiating capability of your enterprise or it is a commoditised capability? For commoditised capability you would not mind going for a commoditised system. Differentiating capability, you would rather hold closer to your chest.
   
   Consider the scenario where differentiating capability is bought. If you then want to enhance the capability, it may need some enabling in the system. That enabler is a valuable intellectual property which vendor gets for free. Not only that vendor will immediately proliferate it to other willing bidders.
   
   
2. Short term TCO vs life time TCO
   Short term TCO of vendor product normally wins hands down vis-a-vis buy option. But when you consider life time TCO, including cost to replace, there may not be much difference in TCO. It is because, for built systems you can let them decay and save some costs before replacing. Whereas in case of bought systems, you need to keep pace with changes thru (sometimes forced) upgrades or else face unsupported obsolescence (quite risky). This works in your favour especially if you are an early adopter and back the right horse. Then building may be better proposition than buying.
   
   
3. Sourcing options
   Vendor supplied systems normally offer more sourcing options but are not necessarily cheap. Built systems are slave to the people who built it and sourcing options are limited. But this does not necessarily mean costly. This depends entirely on circumstances of each enterprise. Especially in case of mergers, retaining talent to nurture the built system may not be easy. On other hand the vendor of a bought system may get bought over or go out of business, thereby obsoleting the system. Which in turn will reduce sourcing options.
   
   
4. Time to market
   Vendor supplied system's biggest advantage is time to market. But this can be realised only when the systems are used straight out of the box. It is rarely the case though. Minimally you would have some integration to do, worse you will have to customise the system extensively to match your requirements. This fits in with the first point above. If its a commodity capability, you would want to use the system as is, with minimal integration. If necessary change the organisation to fit the system. But when its a differenting capability that system support, you would end up doing heavy customisation and integration. This would negate any benefits of off the shelf system.
   
   
5. Time to respond to events
   This is one of the big issue with vendor supplied systems. Where they will provide periodic upgrades and in some cases respond to mandatory changes (imposed by regulation). They are not likely to respond to event which are significant for your enterprise alone. You are on your own anyway. If you have adopted the system for differntiating capability then this would be a big problem.
   
   

Of TLAs and FLAs

In my previous organisation every employee used to have a three letter acronym (TLA) made from employee first, middle and last name, instead of an employee number. There was an anecdote about it as well. The company's then chief, who is also called "Father of the Indian Software Industry" had actually ordered a four letter acronym (FLA). But the software that was used to generate those acronyms, produced a nasty one for the chief. (If you know his name, you can imagine what that four letter word would have been). So he ordered it to be changed to a three letter one. (BTW, Many happy returns of the day Mr. Kohli).

It appears to be going in reverse within IT. In IT, there were a lot of TLAs. ERP, SCM, CRM, EAI, BPM and SOA to name a few you may have come across. Of late however the trend is moving towards FLAs, what with SaaS, PaaS and so on. However the most enduring acronym which survived the test of time is neither a three letter one nor a four letter one. It is actually a five letter one - RDBMS.

The reason it has survived for this long, is because it is more than an acronym. It is a well thought out piece of technology backed by solid science. It is not just an acronym coined by sales and marketing guys nor an industry analyst. This technology has proven to be easily standardised, exetensible and serving the vast array of requirements some of which was not even envisaged when technology was initially developed.

Sadly same cannot be said of all the technologies you see around these days. Many of them are rehash of old ideas in new packaging. They rely on finding the right audience at right time to proliferate and thrive on inherent problems they carry to generate more revenues for their owners.

Enterprise architects need to possess the vision to see thru the marketing fluff and reach the bare bones of technologies they are going to employ. Analysts can help to an extent, but the generic analysis may not be completely applicable in your situation. You need to equip your 'Oracle' function with this capability.

People or process?

This is an interesting debate going on, that of people versus process in enterprise architecture function. Now that we are on subject let me bring in my perspective.

Legend has it that there were weavers in Dhaka region of Bangladesh, who could weave cotton cloth so fine that a nine yard piece would weigh less than 50 grams. Well that art is lost, because those weavers would never codify that process of weaving. So that knowledge passed only between generations thru word of mouth. When pitted against cheap cloth from Manchester, their better quality cloth lost market share to cheaper but not so great cloth. Eventually the whole craft died. It need not have been so, have they codified the process. At least craft would have survived and could have been revived in these days of green trade/fair trade.

Moral of the story,
1. Not codifying process is no guarantee against obsolescence.
2. Someone who can employ a repeatable process wins in a mass market over someone without process. (And enterprise IT is by no means a niche market).

Having said that I do believe there are job functions which cannot be fully codified by processes. I believe enterprise architect’s is one such job function. But this job can still be divided into pieces that are more defined and pieces which need bit of experience and expertise. The defined parts can then be codified and handled with slightly lesser skill levels. With this approach a full fledged enterprise architect, with some help can do job of many enterprise architects.

Nobody would have been interested in this model, if there was supply of good enterprise architects. Problem is there are not enough good people going around. This is a way to make do with what you have got. And yes it does work in enterprise architecture function too.