Retrospective

Here is a retrospective on some of the blog posts.
Incidentally most of them are also top content on this blog per reader's choice.
So if you are a recent visitor, there might be a gem you may have missed ;-)

1. Agile, iterative or waterfall
   
2. City planning and slum control
   
3. Centralised service delivery team
   
4. Requirements management is crucial
   
5. Challenges in using services as integration mechanism
   
6. Requirements elicitation
   
7. SOA in enterprises or Hype 2.0
   
8. BPM or workflow
   
9. SOA and demonstrating ROI
   
10. SOA Fable: Do you wear a watch
    

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.
   
   

Darwin and enterprise architecture

Today is 200th birth anniversary one of the great thinkers of modern times. Darwin presented us with the theory of evolution, summed up as 'natural selection' or 'survival of the fittest'. We also know that applying Darwinism in all spheres (e.g. social sphere - a la Nietzsche/Hitler) is not a good idea. However thats what tends to happen when it comes to enterprise IT. The evolution of enterprise IT tends to follow, the evolution of enterprise itself. As enterprises evolve, different parts of its value chain become important and get more attention (consequently more resource allocation). This weird sort of natural selection leads to multiplicity of systems and infrastructure, which tend to overlap or in rare cases leave gaps.

Over a period of time, the architectural environment, may it be business, application or technology architecture gets contaminated. This leads to bloated cost base and starts affecting time to market for business change. Approaches such as portfolio rationalisation can restore order temporarily. But to retain some semblance of order all the time, a proper enterprise architecture function must oversee the enterprise IT.

However what I have seen happening in practice is that at best of times the enterprise architecture function gets tolerated at most, and given total short shrift during bad times (such as current times). Focus moves to doing change projects faster and cheaper. The old wisdom is however easily forgotten, in being penny wise on short term project costs and time lines, we ignore the pound foolishness of bloated cost base and compromised time to market for future changes. However I also tend to agree that business change cannot wait for the right architecture to be put in place first. Businesses normally have window of opportunity to cash in, and cash in they will - with, without or despite IT.

Thats where the concept of Enterprise IT Oracle comes in. The Enterprise IT Oracle will let IT predict the future as envisaged by business, and put the right architecture (with appropriate governance) in place even before the need arises. It kind of puts IT in an offside position (soccer/football term) so that when business wants to pass the ball, IT is ready to receive it and shoot it into the goal. It is my firm belief that without such 'Oracle' function, enterprise architecture functions in reactive mode will never be able to rise to occasions.

Enterprise IT Oracle revisited

This post is prompted by James' post about analyst community and their licensing practices.

My thinking is that analyst are resorting to these practices because they feel they are leaking revenue. The revenue is indeed leaked because of sharing of their intellectual property.

If analysts replace their current model with 'youtube' type of model, whereby users are required to connect back to central store every time user wants to refer to content. Then content from this service can be priced reasonably as there would be no revenue leakage and they can earn some more money by selling adverts on such a central store.

They can make this model attractive by different pricing options and it could be win-win for both sides. Wonder why no one from analyst community thought of this yet, as they are the ones analysing market developments!

Wider point is about idea of Enterprise IT Oracle that I had blogged about couple of years ago. What analysts create is insights based on raw data. Analysts make deductions after collecting data from various sources and then apply their experience and expertise to provide insights. No doubt everyone does not possess intellectual dexterity of an analyst, but a collection of people may be able to substitute for one bright analyst. But they would need access to data.

If enterprises could provide online social spaces like 'youtube' within their organisation to accumulate data and then let people provide insights or judgments on these, then the collective intelligence of work force may be able to offer analyst grade insights on data that enterprises have. If you have access to enough raw data within enterprise this is worth trying.

Two computers per employee

There is an initiative to provide children in developing world with a laptop each. Which is very laudable. What will you think if I were to tell you that enterprises too have similar initiative. They are spending money, even in these turbulent times, to put an extra desktop computer on each employee's desk?

Well that's what you do when you put a specialised VoIP phone on each desktop. A VoIP phone is nothing but a computer which runs only one application, viz. a telephone. Of course there are applications, which can run on your existing desktop PC and provide same functionality - popularly known as Soft Phones.

In fact providing soft phones to every employee, especially those on move, will make more sense. Then they can use those soft phones to connect to the world while on move, while spending only on ISP connection.

So why does not this happen? Why we keep seeing those ubiquitous VoIP phones on each desk? 

I would attribute this to ineffective enterprise architecture governance. If you know how decision to introduce VoIP is made, you would understand my point. VoIP is typically introduced as upgrade to existing telephony infrastructure. Fact is,  it is NOT an upgrade to existing infrastructure. If you were to replace twisted copper cable network with optical network, that would have been an upgrade to existing infrastructure.  Introducing VoIP phones is same as introducing a new application in your enterprise, and hence should be subjected to same level of governance rigour to make sure it is consistent with your enterprise architecture and you understand full implications of your decision. 

When you decide to use a specialised VoIP phone over soft phone, you are implicitly stating an architecture principle, 'Appliance over application'. If you chose this principle, then adding extra capability (say ability to send faxes) may require a new appliance. Whereas if you chose 'application over appliance', it might be a simple feature update to existing application. See, what I mean?

I would rather have this principle established out of an enterprise IT oracle function rather than through sales pitch of a vendor.

EA Governance

It has been a while since I posted on this blog. This discussion initiated by Todd is of some interest to me and got me motivated to post this entry.

I had spoken at Open Group Conference, about the same. My presentation can be seen here (subscription required).

My concise picture of EA governance is as below.


The governance function of EA can roughly be divided into three broad categories, viz. legislating, ensuring compliance to legislation during execution and adjudicating the non-compliance.

When people talk about governance they mainly talk about compliance and adjudication, as pointed out by Todd. But for me the most important piece of governance is legislation . That is - when principles, policies, standards and references, which defines the compliance framework, are set. A broader community participation at this stage and a feeling of belonging, improves the compliance and lessens need for adjudication. Otherwise it appears that EA group is pushing its own agenda on practitioner community and practitioners actively resist such a push. Which leads to a lot of adjudication, requiring lot of management attention.

I am not saying EA legislation needs to be a totally democratic process and must follow democratic norms. But at the same time, it should not appear to be totally autocratic top-down process, thrusting legislations down practitioner's throat. In large IT organisation critical projects get caught in adjudication cycle and EA gets bad press precisely because legislation has not taken on board various points of views.

That reminds me of the role of free press. If we compare EA governance to civic governance, the piece that is missing is 'Free Press' or a communications function. It is a bi-directional communication channel which informs practioners of strategist's intent and allows practitioner's to report back their experiences from trenches to strategists, so that strategies can be suitably altered.

The social media is a good candidate for fulfilling all these functions. It can be utilised to empower the practitioner community to participate in legislation process and can also function as 'Free Press' so that bi-diretional communicaiton can take place between strategists and practitioners.