Dont build for reuse, reuse what you have built

All architects are very passionate about reuse. The reuse is one of the most admired and promoted principles. And often enough business sponsors of IT project seem to spurn the extra funding required to make ‘something’ reusable. That’s an irritant faced by most architects. So what is the problem? Why this seemingly smart person from business side cannot see the wisdom of building something for reuse and spend that extra cash? Is it possible that they are smarter than architects? Probably they know, by spending that extra cash they are not really going to get that reusable artifact.

May be we need to turn the argument on its head, to get the business sponsor’s perspective. Imagine an architect saying to sponsor, “Don’t give us extra cash so that we build something reusable, rather well save some cash by reusing some of the existing artifacts.” [That will be music to sponsor’s ear.] However it is a difficult statement to make.

An architect will protest, “How can we reuse something, which was not built for reuse? How do we know how well the artifact satisfies my functional requirements, let alone non-functional requirements? If I have problem in re-using it, who is going to help me out? How much additional effort I am going to spend in understanding and plumbing it with rest of my solution? Is that effort much less than the effort I would have spent in building it myself? Do I save on maintenance or am I doing ‘clone and change’ reuse?”

If you look at it, most of this applies to something which was built for reuse too. How does one build something for reuse in a potentially unknown future scenario? With unknown functional as well as non-functional requirements? What organization (and of what size) one needs to support this reuse? Difficult questions! So being a pragmatic, I am inclined to give up the notion that something worthwhile can be built for as-is reuse in future, and tend to agree with those (smart!) business sponsors. Wait, before you declare me a traitor to architect community, I would like to state that some reuse is still possible.

What I believe is a reuse at conceptual level is still possible, and useful. So if we separate the concepts from implementations (a la MDA, CIM v/s PIM v/s PSM), we can reuse the concepts already built. And choose a more appropriate way, to connect with an available implementation, for the current scenario. What are these concepts? They can be anything conceptual, a business process, a conceptual data model, a set of business rules. They are closer to business requirements than IT design or implementation. Most probably you will use fragments of these conceptual elements than complete conceptual element. Does this need a full blown MDA tool set? No, not in my opinion. One needs to separate concepts from implementations using any notation that one is familiar with and have a repository of such concepts. So any new solution you are going to build, first step would be search in this concepts repository. You find something useful, (re)use it. The effort and organization needed for creating and maintaining such a repository is not huge. And of course you need to adopt a slightly different solution development practices to institutionalize this. [Well for a small consideration, we can help you there ;-) ]

So, don’t build for reuse, rather reuse what you have built!

Is single version of truth achievable?

Did you have a programme in your IT organisation to build 'the single view' of data for some subject area, say Customer or a Product? These types of porgrammes have different names Book of Records, System of Records, Single version of Truth and so on. Have you experienced the agony one goes thru to try and create a single view, acceptable to different view points that exists in an organisation? There always will be some view point, which would want some data at different level of granularity or different level of currency or both, from rest of the view points.

No I am not talking of CDI/MDM. The problem I am talking about is about defining what 'the single view' of a particular subject area should look like? Even after you decide how your single view of subject area should look like, there are further challenges of collecting, reconciling, cleansing and hosting data. Thats what CDI/MDM predominantly addresses. But who helps you in deciding what the right single view of particular subject area? Frankly, nobody.

So isn't a single view of a subject area, a misnomer? Let me make a logical argument. even when we build an IT system, we start with a nice third normal form data model. But the non-functional requirements, such as performance, scalability makes us abandon the third normal form data model and introduce level of redundancy, what we poularly call denormalisation. And we live with it.

Why not take a similar approach to data, at enterprise level. Lets accept the fact that, the different view points are not always reconcillable, and the single view of subject area is impossible to achieve. Why not build a fit for purpose single view of subject area. And there can be as many single views as there are different purposes. Some of the purposes may collaborate with each other and can reuse each others single views. So in reality there can be less number of single views of subject areas than the number of purposes. Ofcourse, you need to create mechanisms to keep these different single views in synchronisation. Well why create one level of indirection, why not go to multiple view underlying this single view directly? May be using a service facade? Well I have answered these questions in one of my earlier posts . so you would need these fit for purpose subject area single views. You can use MDM/CDI technolgies to build them.

And if you dont believe me then I have a bridge to sell you ;-)

Communism and enteprise architecture

It is important one learns how to solve common problems using patterns. It is also important how not to solve problems using anti-pattern. One of the greatest anti-pattern relevant for enterprise architecture, comes to my mind is Communism.

Communism is an ideology that seeks to establish a future classless, stateless social organization. There is very little for one to disagree with this noble goal. The problem arises when one tries to follow the migration path from 'as is' state to this nice and wonderful 'to be' state.

Enterprise architecture seeks to define similar nice and wonderful 'to be' state for enterprise IT and tries to provide a migration plan from seemingly chaotic 'as is' state. Therein lies the similarity and lessons for EA. What are the important lessons to be learnt from failure of Communism?

Centralised command and control alone cannot guarantee results

Enterprise architect sometimes try to rule by diktats. Thou shalt do this and thou shalt not do that... These setting of common principles are necessary. But failure of communism teaches us that a central politburo can command whatever it likes, but things need not happen on ground as per their diktat. At least there is no guarantee that spirit of these principles (diktats) would be observed. With just letter of the diktats enforced, expected results will not follow. So there should not be too much of dictating and whatever is dictated must be governed to make sure that it is followed in letter and spirit.

Evolution, rather than revolution, works

Communist ideologues decided that the current system is too broken to be fixed, hence they advocated a violent overthrow of current system and replacing it with a new (better/improved) system. such a revolutionalry approach did not work in practice. It is indeed nearly impossible to design a system from scratch as replacement of another working system and replace old with
new, in one go. It is more adivisable to chip at problems of old systems, replacing parts of it as we go along. It is also important to keep readjusting priorities as we go along, because nothing in this world is static.

Checks and balances are required in governance

Another ill effect of centralised command and control was corruption and general in-efficiency. The middlemen prospered without adding any value. So a proper set of decentralized checks and balances is absolutely a must for efficient governance. In enterprise IT world, business and IT folks exhibit certain amount of tense relationship. So EA must create a balanced mechanism where both sides are represented and heard, and decisions are made which are acceptable to both parties.Including all stakeholders, is a must for efficient governance. This would insure right solutions get developed and not poilitically correct solutions.

Stakeholders involved must buy into 'to be' state

All communist states had a significant number of capitalist who would never agree with 'to be' state, as stated by communist. So communists could never reach their desired 'to be' state, no matter whatever their migration plan was. Mind you these capitalists were not just ideologically capitalist, rather they had a stake in being capitalist. Pol pot, one of the communist meglomeniac, tried to address the problem by eliminating such dissenters on a mass scale. Even that did not work. So it is very important that a significant section of the bsuienss and IT organisation must buy into the to be state. Without which there will be too much friction and resistance to change. This needs to be remebered in conjuction with item 2 above.

People involved must be able to connect current happenings with 'to be' state.

The empty store fronts and long queues for daily essentials in communist states were not reconciling with tall claims of progress by central politburo. The communists did put man in space, and fired giant rockets. But where it mattered the most, daily lives of their stakeholders, they failed to deliver. Enetrprise architects also fall into similar trap. Having a set of principles, a town plan and what have you, will be taken with pinch of salt by common IT and business folks, unless you show the results on ground. Stakeholders must be able to connect things happening around them to the grand vision of enterprise architects, based on the results they have seen so far.

These are only a few of the lessons learnt from failure of communism, enterprise architects can keep learning from history of communism and make use of it as an effective anti-pattern.

Demand supply mismatch in IT shops

Demand management in enterprise IT shops is a perennial problem. The problem is actually of demand supply mismatch. There is a gap in the demand of qualified IT professional and supply, to serve the ever increasing IT demand from enterprises. This assertion is based on personal experience and I dont have any data right now. My observation is that, many big enterprises I have worked with, invariably have a big IT backlog.

Enterprises have tried various options, including outsourcing to tide over these issues. Outsourcing orgnisations have bigger resource pool of qualified professionals, and other enablers to help match demand. But there are situations where even outsourcing does not help in handling demand supply mismatch.

If lack of skilled professional for a particular skill is a reason for demand-supply mismatch,outsourcing can help here. Whereas,if lack of smoothening of demand for an entity within IT, making that entity a bottleneck is the reason for backlog then steady state outsourcing does not help. Which in turn gives rise to more of demand supply mismatch. Mind you this is not some fixed entity within IT shop. Any entity can be sucked into this situation based on its role within various IT projects that are going on. If your IT shop is organised on basis of SDLC roles then that entity can be pool of senior designers, system testers, even enterprise architects. Or if your IT shop is organised based on architetcural layers, then it can be front-end , business logic unit or database unit. Or if your IT shop is organised based on functional component then it can be any of the functional component.

It might so happen that large number of projects starting now, are going to hit that particular entity around the same time causing the demand surge.

What can be done to handle such situations?

One obvious solution that comes to mind, is dont start all the projects at once. But the problem is one cannot predict future demands and the situation can still arise even if you deliberately defer the projects, some other project might crop up in future which will have other imperatives (like business or regulatory) to start and cause the deamnd surge. Also the project budgeting and planning of IT shops happens periodically, which does not help. Well one cannot really have these activities aperiodically, so whats the solution?

Solution again is outsourcing. What we have seen earlier is a case of pro-active outsourcing, which does take care of some problems. For the problems arising out of demand surge, can be handled by re-active outsourcing. Outsourcing does offer an advantage, in terms of making IT expenditure 'variable cost', thus committing and withdrawing resources is easy. So IT shops can work out deals with outsourcing companies on a contingency basis, commiting some resources permanently to this continegency resource pool and an agreement to ramp this pool up in case of demand surge, ramp it down when demand ebbs. The advantage being

1. Outsourcing companies do have resource pool which can absorb these demand surges.
2. Outsourcing coupled with offshoring makes this otherwise dead investment, economically viable.

Outsourcing companies will have global knowledge, and can work out deals (billing rates, utilisation etc.) to their advantage. Its a win-win proposal.

And as an EA it makes me happy, because none of my strategic projects will be derailed because of demand-supply mismatch.

Evolution of an IT worker

IT folks, early in their life think, technology has solutions for all the ills within enterprise IT departments. There is technology solution for every problem. Something does not work, use that tool, automate this, do straight thru processing.

After a while they realizes no amount of technology is going to help unless there are proper processes. This is second stage of evolution, now with technology, processes are deemed necessary. Our IT pro is on process building spree. He may even build processes to define processes. And then after toying with technologies and processes for a while, he realizes it is not really having desired effect on enterprise IT scenario.

Thats when he realizes importance of people. Empowered people, who has bought into your ideas can make things happen. This is the next stage of evolution. Everything is achievable by right kind of people, we dont need any technology and/or processes.

And then when this people only approach fails miserably then our IT pro achieves his nirvana by recognizing that it is the judicious mix of right amount of technology, effective processes and efficient people is what makes IT work for an enterprise.

It is very important for an enterprise architect to bear in mind, this evolution. For he has to deal with folks at different level of evolution. He will have to work with many technology task masters, a few process pundits, fewer people's politicians and even fewer who have achieved IT nirvana. To keep delivering right enterprise arcitecture and sustain it, he has to take all these people on board and make use of their enthusiasm and leanings properly. Within themsalves they present right mix of people to define, build and govern an efficient enterprise architecture organisation.

Needless to say an enterprise architect must have reached this IT nirvana himself, to realize this.