Google Chrome OS - I told you so

The Google Chrome OS announcement is a 'I told you so' moment for me. Nothing pleases an analytical mind than when the prediction borne out of analysis turns out to be true. There are enough doubters, doubting motives, timings of this announcement. But I always thought this would happen. Google is not at war with Microsoft, rather it is enabling the uptake of 'the Cloud'. As for enterprises, I see every reason to latch on to this trend. This presents an opportunity for enterprises to free themselves from clutches of desktop OS, its incessant upgrade cycles, security vulnerabilities and limitations it imposes.

I remember a conversation I had with one of my friends regarding the same subject just after Chrome browser came out. When Chrome browser came out, every one was treating Chrome as just another browser and questioning need for one more browser. Then I had stuck my neck out and contended that it was not just a browser but a prelude of things to come. It was indeed a light-weight front-end to a light-weight desktop OS. I was not sure how fast this would happen. It looks like it is happening faster than I thought. And my second contention is that it will enable enterprises move to the Cloud, faster.

In my opinion the consumer market will be conquered by the smart phone and netbook. The enterprises on the other hand will only need netbook class devices than smart phones, but not with the bloated OS of yore. Chrome OS with a netbook class device will be a perfect choice for enterprises. Current legacy can be hauled off to cloud and exposed as a plug-in on Chrome browser. And there is no reason why back-end services, yet to be built and which will reside in the Cloud, need to be provided only by Google. In fact, this Chrome OS - with open standards based front-end, will bring in much more transparency and Independence from OS, for service providers. Chrome OS, in essence is taking desktop OS out of equation within enterprise IT.

Coming to think of Chrome OS, it has potential to change the enterprise IT, the way switching technology changed telecommunications. Now in the days of packet switched network, circuit switching looks so much of a retarded idea, even though it was the only possibility during initial days of telecommunication. But when packet switching became practical it changed telecommunication beyond recognition; changing the architecture and business models. Similarly a computing device capable of doing everything locally and storing all it needed - locally, looks so 'Stone' age in the age of ubiquitous network connectivity and elastic compute/storage capacity. In that sense Chrome OS with a browser front-end is set to change the architecture and business models of enterprise IT forever. Desktop OS had its run, now its time for it to move on and vacate the place for Chrome OS. Mind you demise of dominance of desktop OS does not necessarily translate into demise of Microsoft, the same way the demise of dominance of mainframes did not kill IBM.

Indeed we live in interesting times. We have an year to prepare and fine tune our strategies and architectures. Don't miss on this opportunity.

Business IT alignment: Who cares?

Business IT alignment is a topic that generates heated debates and outright ridicule sometime. There is a Gartner fellow, who declared, "None of you are in IT, all of you are in business". Then some one else claims why IT is so special, no one talks about aligning Finance and Accounting to business. The general feeling is that, it is a non issue.

I beg to disagree. All of these commentators are missing the point. IT and business need alignment, specifically because IT is not like other support functions of business. IT is not finance, accounting, HR or legal. IT IS special. And why is that so?

It is because IT is not only useful operationally or tactically, but can provide significant strategic and competitive advantages. It is not only useful in automating operations or producing relevant management information but also can add new market segments to business, open up new distribution channels, or sometimes add new lines of business. It is this capacity of IT that should allow IT to go ahead on its own strategic vision. IT going on its own and doing its own thing, is good for business. That unfortunately gives rise to issue of alignment.

Business leaders need to understand making IT just an 'order taker' for business removes any incentive for IT to contribute in this unique way that no other support function can. Enterprise IT function can use the building blocks available in market place to create the differentiators for the business. This unique function can not be totally trusted to a vendor.

This is especially true in case of banking, financial services and insurance sector, where essentially business is nothing without IT (and of course a lot of capital). Most business in this segment derive their USP from IT and must treat it as strategic asset (and most do). So when attempting to align business and IT, don't make IT totally subservient to business. There are multiple perspectives of alignment. IT being sensitive to business strategy is necessary but not sufficient. IT strategy must also respond to external IT world and bring relevant changes into business, whether dictated by business strategy or not. So business leaders need to be even handed and do a 'complete double loop' of alignment so that IT strategy has a chance to make difference to business, and IT is not just taking orders from business.

As business and IT strategies can be at loggerheads at times and that will make alignment difficult. But make no mistake, business IT alignment is required for optimal results and IT strategy need to be given some degree of freedom.

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.

Oracle's Java

Normally when I refer to 'Oracle' on this blog, I refer to 'Enterprise IT Oracle'. This time I am however referring to Larry Ellison's Oracle Corporation on this blog. It is because its acquisition of one of the significant technologies of 21st century, viz. Java programming language and associated paraphernalia.

This is BIG. Large chunk of enterprise IT is done these days, using Java technology and it is assumed to be 'De facto' and 'open' standard. Now with Oracle's acquisition of Sun, the openness of Java is under question.

What should organisations with large Java investments do? Well IBM is one of those, with large Java investments. Most of IBM's Internet stack under WebSphere brand is based on Java. What would IBM do?

What would other hardware vendors like HP, Dell do? Do we see three hardware blocks emerging? Sun/Oracle, HP/Microsoft and IBM? Where would Cisco/Google servers fit in this scheme of things?

Continuing this analogy would we see three software blocks viz, Java, .Net and possibly IBM's own Java like technology (may be a rehashed EGL with its own byte code) emerging?

Will cloud providers be bound to one of these blocks? If these three blocks start erecting Chinese walls around themselves, in order to lock customers in, then how does one allow seamless movement from one 'cloud' provider to another?

What would be de-risking strategy for enterprises, to avoid a lock-in within one of these blocks, even in an on-premise scenario? Does MDA sound attractive now? Is it the time that enterprises start focusing on separating their intellectual property from execution platforms?

Interesting times. Time to activate your enterprise IT Oracle and see which parts of Enterprise Architecture needs re-looking.

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.

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.

SOA - Dead or alive

I had doubted SOA hype years ago in this post about SOA hype. Recently a small storm was raised when Anne Thomas Manes of Burton group blogged about untimely demise of SOA. But curiously, I am not so pessimstic anymore. My feeling is that SOA as an arhcitecture style is now better understood for what it is, than a magic technology silver bullet intended to solve all of enterprise IT problems. This short post from Ali is quite insightful in that context. What it is suggesting is that SOA has moved on to next step on its evolutionary path. Which is a good sign.

I always believed the true value proposition for SOA was not sharing (a.k.a. reuse) of services, and definitely not cost reduction. As sharing is important for provider who has mass consumers adding further value to digitised services provided. In enterprise scenario this may not be of much importance, unless you are in business of provision of digitised services. But sharing was a necessary step before SOA moved on to next stage of evolution where it makes more sense for enterprises, which are not in business of providing digitised services to masses for further value addition.

This is because sharing of services requires service contract standards(WSDL) and service discovery standards(UDDI) albeit in weak form. It also needed mechanism, to determine what is to be shared and at what granularity, to be established. These standards and technologies are in place and mature now. With these in place, implementing shared service is quite straight forward. It also set stage for next step of this evolutionary journey.

The next step of evolution, viz. flexible services where flexibility is at hands of providers, is progressing as I am blogging. The charge is led incidentally by progress made in BPM world. The more we know about processes, process composition and orchestration especially in a human task centric processes, we will make more progress on flexibility aspet. It would throw up its own set of standards and technologies, e.g. BPMN, Services Fabric based on industry models etc. So having process standards and technologies create need for limited sharing of services, which now can be provisioned using standards and tools in place already. At this stage benefits of SOA start becoming visible for enterprises. It would show up as agile and flexible processes. Processes which can be measured, monitored and flexed easily. When this becomes mainstream then stage will be set for ultimate goal of SOA, viz. flexibility at hand of consumer (a.k.a virtualisation).

I believe for virtualisation to become mainstream we would need ability to procure, provision & manage services in a location independant manner(a.k.a. in the cloud). We would need some form of semantic compatibility guarantees on the fly (kind of expected in semantic web). At this stage of evolution we may also see an ITIL like methodology evolving for business service management. I also believe it is not necessary for all services to be virtualised. What services need to be virtualised in what context would remain a very specific decision for each organisation. (Or you end up finding your business getting disintermediated using the services provided by you).

So don't let all the doom and gloom news get on to your nerves. It may be just current economic climate reflecting in people's feelings. It may not be possible anymore just to declare an IT project as 'SOA' and get funding from business. But from an enterprise architecture viewpoint SOA looks well set to be de-facto architectural style of IT in future.

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.

Consumer IT and Archimedes

The rise of consumer IT means, everyone now is acquinted with various hardware and software artifacts. Many people have network routers at home, can create a small home office network all by themsalves. Make various applications on different computer work together. They can make applications share resources like printer, fax and scanners. They share data like photos and music across their own network and indeed over internet. They collaborate with their friends and family using voice and non-voice channels.

Some of these people are decision makers in corporate world. When they compare the ease with which they themsalves can make this happen, to their experience with enterprise IT, they get a rude shock. Some of them then start suspecting enterprise IT organisation of ineptitude and incompetance.

But they are wrong. As was Archemedes. Archemedes had famously said "Give me a place to stand and I will move the earth!". We now know, how wrong he was. For according to the "golden rule" of mechanics, the mechanical advantage derived will always be accompanied by a loss in displacement, or, in other words, in time. Even if Archimedes had been able to push the lever with a speed of 0.34 km/sec the speed of sound, he would have lifted the earth by one centimeter only after 93,264,094,069,895.84265 years. [More details can be found here.]

The question is of 'scale' and complexity introduced because of scale. One cannot project consumer IT experience onto enterprise IT on a linear scale. The non-architected approach that works in consumer IT scenario will not give same results. Moreover home networks and applications never grow beyond a certain threshold, they are changed more often without any worries of backward compatibility, ground up rebuild of whole application set is possible and indeed practiced. The enterprise IT behaves differently on these counts on account of scale, complexity and requirements from users. 

Archemedes anecdote tells us follies of projecting experiences from small scale to large scale. So, please, don't ever say "I can do it myself, with stuff from 'PC World'." 

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.

Google Chrome: Beginning of a new future?

The new browser released by Google is first nail in the coffin of desktop OS in enterprise computing. Chrome has taken over process management. It needs OS services only for hardware access. Wait for a Google VM directly accessing a hardware abstraction layer. Next step would be, to make it available on BIOS, enabling a full fledged diskless desktop.

Now most desktop applications are available over Cloud. They are interoperating with existing apps. So this is highly desired by many large organisations fatigued by desktop OS upgrades.
The future would be applications accessed by a Chrome like browser in Cloud (or for those who still prefer on-premise applications, there still may be appliances) from a diskless desktop.

Looks like this is beginning of a new future and end to enterprise computing as we know it. Well not really, we had exactly this situation earlier when 3270 terminals accessed big mainframe apps. Difference this time is

• The new diskless desktop will be more powerful than 3270 terminals and more multi-media capable.
• Network and protocols would be open standards based than proprietary.
• Software ownership model will be replaced by software tenancy or pay per use model

I am accepting bets on how fast this is likely to happen!Three, Five, Ten, Fifteen years?

Enterprise architecture: The missing link of business IT alignment

Business IT alignment is an issue most large enterprises grapple with. Normally there are separate organisational units for strategy and operations in enterprises. The business strategy unit formulates business strategy as a response to business drivers. Business leaders know, how to translate their business strategy into actionable items for business operations. That insured alignment of business operations with business strategy. IT strategy organisational unit formulates IT strategy, which needs to react to IT drivers in the market. IT organisations too are quite adept at translating IT strategy into actionable items for IT operations.

The problem arises when business strategy needs to cross over into world of IT operations for implementation. Or when IT strategy needs to cross into business operations for implementation. And more often than not, this is the case. This has been quite nicely described in an article [“Strategic Alignment: A model for organisational transformation through information technology,” in T. Kochan & M. Unseem, eds,Transforming Organisations, Oxford University Press, NY, 1992] by Henderson and Venkatraman, quite a few years back.

And each time the cross over happened, translation is required to and fro between these organisational units.Enterprise architecture function is on the cross-roads of these four arms of business, carrying out that translation. Since EA function is at the boundary of strategy and operations, it has to deal with both 'Micro' and 'Macro' at the same time. For the same reason it also has to deal with 'What' and 'How' at the same time. The key is to understand, that while EA is accountable for 'What' and 'Macro' part, it is responsible for 'How' and 'Micro' parts.

In lay persons terms, at strategic level the EAs are influencers. Their advise is accepted in making decisions. This role is bestowed upon them because they are thought to be capable of making things happen on the ground. The decision makers listen to EA about 'What' part because they expect EAs to take responsibility for the 'How' part.

Following this logic clarifies the duality of EA role.

• Strategizing and architecting at Macro level
• Consultancy and Governance at Micro level
  

While EAs want to spend more time on former than later, their wish may or may not be granted based on maturity of the IT organisation. And I am afraid, that is a sad fact of life in enterprise IT.

Does IT matter?

It has been more than five years since Nick Carr made his prediction about IT becoming inconsequential. His argument was that IT will become so standardized that it would cease to have competitive advantage. IT would roughly follow a utility provider type of evolutionary path. Since then we have had great strides made in Cloud/Grid computing and it appears IT infrastructure is on its way to become standardised. Though I have made points about capacity issues here and here, except for one major incidence there is no other slip up yet. Many of components (the Intellectual Property of IT), sitting on top of IT infrastructure such as ERP, CRM, BPM too, are standardised to great degree. So are we really going to have a standardized IT environment and hence IT would not matter strategically?

IT was necessary and sufficient for competitive advantage till some time back. But with the standardisation and proliferation of IT, it has become necessary but no longer sufficient for competitive advantage. What that means is just investing in IT will not give companies the strategic advantages. It however does not mean that IT investments can be simply cut back. So enterprises are going for the more bang for the buck thru outsourcing of infrastructure and business as usual activities, and the utilising the savings for transformational initiatives.

The next focus area for competitive advantage will be driving out risk in implementing these standardised capabilities. The enterprise who could implement these capabilities faster and reliably, will get the advantage. In my opinion we are in middle of this phase. This is when enterprise architecture and project management practices are being defined and utilised to its fullest. Over a period, these implementation practices too will be common place.

Then there still may be opportunities to gain competitive advantages thru IT. Unless you believe there are limits to human mind and how much it can innovate - this is a distinct possibility. But the investments needed for such endeavours will be so high that, only outsourcers will invest in innovation and then charge enterprises differently thru differentiated offerings. Once that happens, the utility model will break down and enterprises will start moving to a non-utility model. It does not happen to utilities, because what utility companies distribute is indeed a commodity (well you cannot give more pure water to some of your consumers and charge more, can you?).

We are back to square one, aren't we?

That to me appears to be future of enterprise IT. So IT would continue to be of importance to enterprises, but enterprise would squeeze more value out of IT by using IT as shared utility rather than a captive resource. And this in the end it may result in IT becoming a captive resource again. Well this has happened in past. I wasn't born then, but I have heard stories about IBM Service Bureau and their shared services model.

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.

EA and structuring IT change portfolio

There is no steady state for EA function, as EA has unenviable job akin to converting a propellar driven aircraft into a jet aircraft, while flying. And it does not stop there, by the time EA managed to turn into a jet aircraft, new scramjet is already available and waiting for being adopted.

To cope with this constant churn, the usage of EA frameworks is widespread. But, as I had pointed in my earlier post that results on ground are only thing appreciated by end-users. This post by Tom re-emphasised the point about operationalising the Enterprise Architecture as had this post by Sam. Operationalisation of EA is what is capable of producing the results, no matter what framework was used to structure thinking and what artefacts were built. Unfortunately after spending lot of bandwidth in think and build activities, there is little spare bandwidth available for operationlising the EA.

In a large enterprise, structuring the business IT change portfolio is a great opportunity for EA function to make sure EA is operationalised. Its where the lack of bandwidth affects the EA function. Somehow this important activity uses arkane practices similar to waterfall model followed in SDLC. It is no better than business folks placing their bets on initiatives, based on gut feel of a few individuals.

It need not be so. If you look at large scale picture of enterprise IT, it is a fractal. So what works for structuring changes for a single application can work for enterprise IT too. For an application change, one carries out impact analysis, based on functional and non-functional requirements to figure out the changes required. Similar approach can work for enetrprise IT too. The functional requirements coming from business and non-funcitonal requirements coming from EA group. There are two critical differences though. Firstly requirements for an application are far more crystalised than business requirements meant for enterprise IT. Secondly the understanding of single application is much more rigorous than entire landscape of enterprise IT. Any approach used to structure the IT change portfolio must bear these facts and evolve a strategy to handle it. Any investment made in this area will go long way in establishing EA credibility within organisation.

Centralised service delivery team

Typically in business IT world, budgeting and portfolio definition phase determines what business benefits should be targetted for in a given period and what is the maximum cost that can be paid to achieve those benefits. Business projects are then executed to deliver business benefits while minimizing cost and time to get those benefits. So notwithstanding the various benefits of building reusable services for enterprise, projects tend to do point solutions. Mainly because of these budget and time considerations.

In response to this situation, one of the best practices that has evolved in SOA implementations is to have a central team implementing services for business projects. This has been a good idea. It can address many of the governance challenges. Mostly because this central service team (lets call it services delivery team - SDT) is managed and governed by principles set by enterprise architects for SOA, rather than budget and cost considerations alone.
However there are a couple of challenges in putting this to practice.

• Having a right engagement between project team and this SDT is a big challenge. This engagement model breaks or makes the future of SOA, in the enterprise. It is vitally important to get this model right.
  
• Getting the composition of this SDT right is another challenge, that must be addressed.
  

Initially the SDT was set up as an island, which owned the services and its interfaces. The SDT utilised existing capabilities or whenever necessary got the capabilities built. The engagement between project team and the SDT, was mainly of an outsourcer - outsourcee type. The project team defined its requirement and threw those over to SDT. Which then worked out the interfaces (keeping in reusability in mind). Then further outsourced building of capability required (if ncessary), to teams maintaining the systems which might provide the capabilities. The SDT had only application architects and high level designers apart from project managers. So the role of this SDT had become that of a systems integration designers and SOA standard tools had become SI tools.

This mode of working had turned into a waterfall life-cycle model, partly because the way engagement worked. This started to add a lot of overheads in terms of time and effort to project estimates. At the same time, benefits were not immediately realised for projects. As a result project team started resisting this engagement model, which in turn was viewed as rejection of SOA by project teams (which it was not). When project managers are measured by budget and schedule compliance alone, it was natural for them to resist this engagement model which took away the control of deciding how much budget and schedule risk they can afford to take. So SDT too are facing problems.

I think a new co-sourced engagement model needs trying out. In this model, services delivery team works as part of project team, governed by same budget and schedule consideration. But they are also governed by SOA principles too. So when these two governance principles contradicted, comporomises were required to be made. These compromises were inevitably are made in favour of project. Rarely in case of strategic services, the compromises are made in favour of services. These compromises, in their wake, will leave what I call 'non-'services. Some of these non-services need to be refactored into services by a part of service delivery team, which gets its funding straight from CIO. This team has limited funding, hence could only turn so many non-services into services, resulting into a back-log. Over a period of time, size of back-log would give a fair understading of the costs involved in making tactical compromises against strategic imperatives. This model needs to run for some time, for its efficacy to be known. For this model to work, it would need strong SOA governance framework and a strong testing facility in place.

Any sharing of experience in this area is most welcome.

City planning and slum control

Since we are talking about Enterprise architecture as analogous to city planning, I thought I can bring in my developing world perspective about how slums develop in a city despite having a nice city planning guide, in order to bring out importance of having policies for dealing with slums as part of city planning guide.

In developing world, we are quite used to slums springing up in a city despite having a city planning guide. A slum is a microcosm of a city, but without any planning or vision. It is like a city within city, with its own ad-hoc rules and regulations. It does provide some useful services to rest of the city. No doubt it is sign of broken governance but it is not just that. Slums survive and thrive because they are needed for proper functioning of city and they do provide some value to the city. However slums are not desirable. City planners must contain and eventually get rid of them.

Similar situations arise in enterprise IT world, despite having a nicely laid out enterprise architecture, and strong governance. This article discusses some such cases of deviation, but lays the blame squarely on ineffectiveness of governance. While that may be true in some cases, sometimes circumstances force one to bypass guidelines and governance. So what we also need is a framework to rectify situation, post-facto. In city planning analogy terms, we need a proper slum control and removal policy.

To illustrate, let me give this example.

In a large enterprise, they have a proper enterprise architecture defined, as intended by Annie Shum's paper mentioned in this article. There are guidelines and governance mechanism. Based on this a multi year IT plan is drawn. One of the elements of the plan is to build subject area specific data related services. The build of these services are governed by principles laid out in enterprise architecture viz. Build should be iterative; TCO should be low, resultant services must be maintainable/flexible/performant etc. It is also tied to business benefits and this capability is sponsored by a business facing project which is planning to use it in a year’s time. Now this programme is midway and another business sponsor comes up with a proposal to build a slightly different set of services for same subject area (where attributes are very specific to the problem at hand, their granularity is not generic enough and their currency is very specific to problem). This new business sponsor has a solid business case; he is promising to add millions of dollars to bottom line, if this new set of services are made available within a short span of time. There is a very small window of opportunity from business perspective and it does not matter if underlying capability does not follow any of the enterprise architecture guidelines/principles or governance processes, as long as that window is utilized. The matter reaches highest level of decision making apparatus within enterprise (e.g. CEO) and you know who would win the argument. So this set of services are built which does not fit the plan laid out by enterprise architecture, it may not use technologies suggested by enterprise architecture (procuring them in time for this solution, is an issue), consequently it may not use solution architecture laid out by enterprise architecture guidelines.

In short this is a slum that is getting developed in this nice city (viz. enterprise IT) governed by city-planning guide (viz. Enterprise Architecture). And as an Enterprise Architect if you protest too much, I am sure you would be shown the door. You cannot argue with millions of dollars added to bottom line. So what should an Enterprise Architect do?

1. Do nothing. Which would mean more such slums spring up and then it is just question of time before governance and consequently enterprise architecture breaks down totally. So it does not appear a viable option.

2. Demolish the slums. This is possible if what was built, was one off capability and not required on an ongoing basis. So as soon as the utility of this capability diminishes below a certain threshold, get rid of it, completely. If required, by being very stern.

3. Rehabilitate the slums. This is the only option if what was built is not a one off capability but is required for enterprise on an ongoing basis. The reason it bypassed enterprise architecture guidelines and governance was to catch a business benefit specific window of opportunity. One cannot avoid such incidents. What we now need is to refactor this capability as per the enterprise architecture guidelines and governance processes. We need to bring in this capability in mainstream of the enterprise IT. In short we must rehabilitate the slums (if required by some amount of redevelopment).

There may be hybrid options based on specific situations, but an enterprise architecture plan as city planning guide, must provide for this eventuality as well. I have seen this type of issue cropping up more than once. So it is difficult to dismiss it as statistical outlier, not worthy of a strategic response.

CBD, SOA, whats next?

Most engineering disciplines have managed to split their problems into one that of components assembly. Individual components are well defined and engineered to satisfy a very concise set of requirements. The system level problem then reduces to selecting proper components and assembling them to satisfy overall system's requirement.

Doing things this way has its benefits and it is well established by other branches of engineering. Software engineering is trying to do the same, but without much success. Atleast in business IT world. We have tried component based development (CBD) and now trying SOA. But we are not any closer to the pannacea of assembly of components.

What is that constraint, which is preventing software engineering to move to next level? Implicit in this question is an assumption that software engineering wants to move to a component assembly world. Well, I am not sure that is true either. And I am not alone in this thinking, see this post.

So the problem is not entirely technical. It is also of business motivation, and viable business models. In other branches of engineering, craft became engineering, when it promised to bring prosperity to all stakeholders. In software engineering, what is that business model, which will let multitudes of component makers flourish and big guns will just concentrate on component assembly? Is it standardisation effort, that is lacking? Is ultimate end IT user really interested in such component assembly world? Because in business IT world, the enterprise IT is main differentiator for an enterprise, which prevents it from being commoditized as a service or product provider.

These are the hard questions that industry must grapple with. Otherwise, every couple of years we will have, a wave, be it CBD or SOA and as an industry we'll not move much.

Each such wave (CBD, SOA) takes us further than today. But to make that transition to next level we need an industry wide push and not vendor specific attempts. And this must include all stakeholders - viz. business IT consumers, service providers and product vendors. Perhaps OMG can take lead?