"What's next" for integration competency centers? - Part 3

Next in the next-generation strategy kit is: “High degree of collaboration of the ICC across stakeholders that allows more transparency in the engagement and leads to co-creation of methods of delivery/operation of ICC with stakeholders”.

Basic premise for this view-point is the evolution of the working model for ICC. A typical model for shared services has ‘close door’ system or ‘black box’ system. It means that for rest of the organization, this shared services engagement is only for the delivery of service outcomes. For rest, ICC manages internally. It worked fine during early phase of the evolution of this system since it brought relief to other dependent parties from headache of managing variety of matters; now they could just focus on the outcomes from this shared service. But today, this black box is limiting the overall capability of the organization to innovate and improve

With advent of modern social networking and collaboration practices (like wiki, blogs etc.), possibilities of innovation has gone multi-fold. How to leverage the talent, ideas and learning across the organization in integrated manner, that’s the focus of this point.

As I see, going forward..Continue reading the blog...

BPM and application eco-system based integration platforms

Finally organizations are coming to the terms of reality of multiple-integration platforms in their landscape. There was a time in not so distant past when clients were thinking to have a single middleware, struggling to migrate all the legacy of their enterprise on the so called ‘middleware of strategic choice’ (whatever it would have been for them at that point in time) and spending great deal of time and money in this process. Some managed to do, others got stuck in the time warp of technology evolution. And equally for those who managed to do it as well as who got stuck, time did the trick and soon the definition of the ‘middleware of strategic choice’ changed. It meant, those in the good feeling of ‘done with it’ have to again break their head to move the new legacy to the future platform. Those who were stuck it changed the to-be picture from one middleware to other and they were still stuck in their mess. Now what is happening is slightly more realistic and practical I guess. There are two key trends I can see:

Continue reading the blog...

Who Needs the SOA Competency Center in this world?

I can almost call it a trend as I see it happening again and again, case after the case. As soon as enterprises get active on SOA, apart from SOA technology platform and business service pilot concerns enterprises get their ideas bubbling around ‘SOA competency center’. It is an invariable expectation of having some sort of competency center that will give the enterprises whatever they want from SOA. Let me spend few paragraphs here to bring certain perspective to those who might be seriously attached to the competency center for SOA and might be seeking some direction.

To start with, first of all, I don’t believe that there is really something called SOA CoE or SOA Competency Center that can work in real-world. Well, hold on; I have not completed yet. J..if you understand SOA, you will realize that SOA is like a school of thought, it is like a religion or better yet, it is some sort of a methodology for IT solutioning. It is not a new domain in the enterprise architecture like applications, systems, integration etc. Point I’m trying to say it that if enterprises adopt the SOA, the architecture stack in terms of domains (applications, infrastructure, integration, data-stores etc) doesn’t change. What really will happen on the ground through SOA adoption is a metamorphosis of the existing EA stack domains to incorporate new methods and principles in what each of the domains does. Now, this is important to appreciate it because a typical competency center really is a powerful idea to create some sort of shared services structure in the IT organization to deliver a EA domain specific services. Now if SOA is not going to create a new domain in the EA reference stack, then what is this SOA competency center going to do? SOA will influence and result into some new way of doing things for all existing domains in the EA stack. For example, who application designing and solutioning is happening will see some change to adopt SOA. Similar how integration and data stored play a role, some changes will, happen there to adopt SOA. So in simple terms, all EA domains will be ‘SOA-fied’ (few much more while other less and some may not be for now) to collectively make the enterprise SOA enabled.

So here is how I think whole matter can be approached in more pragmatic manner with getting obsessed with the idea of competency center for SOA. To start with, I could like to differentiate a CoE from competency center or service delivery center as I would like to address it more appropriately. A center of excellence as name suggest is more focused on bringing excellence to few aspects of the domain for which CoE is being built. In general, it will be founded around establishment, management and governance of the core methods, standards and blueprints that are required for any specific domain/discipline to bring excellence. At the same time, service delivery center will be more focused around end-to-end services delivery using a shared services model. So with that definition, surely in the existing model of IT service delivery, SOA competency center or SOA service delivery center doesn’t make as much sense. But let me say this also. As strategic long term picture how I would envisage enterprises moving to, a Business Solution Delivery Center is more promising idea that is built on principles of SOA and has integrated competencies of business and IT. Which means, sometime in future, enterprises will have a common entity in the organization that drives the end-to-end business solution by integrating elemental shared services like applications, process integration, infrastructure, business etc. But for now, I’m leaving it as futuristic idea since most of the enterprises are years away from it. To make the approach easier, let us look at three stages where enterprises might have to think of SOA competency center:

1. Very early days of SOA adoption – this is when enterprise has just thought or heard of SOA and it is trying to find ground and explore the direction with it. Now at this stage all that is needed is to get better understanding of what SOA is all about, its relevance to what it promises to change in the organization and various technological options that it has to explore. At this stage, enterprises should create a focused team that is tasked with this exploration task that might involve collaboration with product vendor, external SOA consultant and other industry SOA forums. This team is largely part time allocated on to the SOA initiative, however might have one or two fulltime allocations to provide rigor and ownership.
2. Enterprise-wide SOA program being run for SOA adoption – this is when enterprise has done some due diligence around SOA strategy and is now ready to go on with the organizational change necessary to bring the enterprise at large to SOA-ready state. At this stage, different IT competency centers like CRM competency centers, SAP competency centers, BI competency centers etc . will need to be prepared to deliver their bits for making SOA work according to overall SOA reference model. On top of that, organizations need additional support to establish common directions and strategies for SOA and subsequently govern what each of the competency centers are doing. At this stage, there are two levels of effort required. At one level, enterprises need to continuously establish SOA capabilities. At another level, it needs to engage other competency centers to adopt and deliver the SOA results with overall governance. For this to achieve, all individual IT competency centers will have their small centers of excellence for SOA specific to their responsibilities of SOA delivery. At the same time, Enterprise Architecture group will have additional roles and competencies of SOA in order to drive the enterprise level SOA. So in this case, there is no separate SOA competency center is established. Instead, it is like a SOA adoption task force consisting of EA group, business groups and IT competency center representative that need to come into existence. It is more of a transient program structure as opposed to a fulltime independent service delivery center.
3. End-state of the enterprise with SOA – this is when all that was supposed to happen, has actually happened and enterprise is now running in SOA-enabled state. To large extent, focus and structure is not much different than previous case but there will not be any transient structure in this case. Since SOA is reasonably in the DNA of the enterprise, there will be very little governance structure needed while most of the responsibilities of SOA delivery will be taken care by IT competency centers for their respective role in overall SOA delivery.

With this, my take is that setting up a proper SOA program structure for first two stages is more important than actually setting up a dedicated service delivery center for SOA. However:

• It is essential to focus on the excellence part of the SOA delivery in terms of adherence of SOA standards, metrics of SOA success etc. through appropriate governance structure. It should be housed in the EA group.
• SOA brings in responsibility of designing the business solutions effectively using services methodology for which business analysts should be taking the ownership.
• A capable SOA infrastructure in the enterprise includes strong service orchestration, composition and delivery platform. This is typically housed in the Integration / ESB domain of the EA. I see this as a significant part of the SOA game plan. And hence to large extent, what I would liked to see in the SOA competency center should be taken up by the existing Integration Competency Center. That way, an Integration Competency Center that has been upgraded to provide all necessary SOA infrastructure for service orchestration, composition and delivery will be what I would see as a the SOA competency center. It will work very closely with the previous two core structures to deliver full SOA compliance Business- IT solutions.

To me it made perfect sense to approach in this manner. But again, I will be glad to hear the alternative perspectives.

Are you in a hurry to implement SOA?

My experience with some of the enterprise clients in SOA space has been rather surprising. I find lots of these enterprises rushing to create a SOA roadmap and deploy a pilot SOA program. My trouble is not that they want to do it fast and want to have quick win but having it done at the cost of 'insufficient' understanding of what they want and why they want is my worry.

Unfortunately SOA is not a topic that is as straight forward and clear as all of us would like it to be. On top of that, when I see enterprises rushing on the SOA initiative, I see that as an early indicator for the disaster in making. What I had been doing in such cases and I also recommend the same to other SOA champions across the globe (who share the problem and potentially the view-point) are summarized below:

• It is utmost essential to ask and understand why a particular SOA initiative is being launched. And answers should not be in terms of 'deliverables' but in terms of 'results'. At times I found that the actual problem statement shared by the client can not be solved by SOA and there was no clarity why SOA is being considered. So beware of such mismatch of problems that client might be expecting SOA to solve.
• Next important thing to pay attention to is the scope. Is prime scope of SOA initiative limited to 'Integration/Broker' technology betterment or does it include any other enterprise domain? If its only limited to integration, then one need to ask and understand what 'results'/'differences' will this SOA initiative bring so that validity of the strategy can be established.
• If you are creating a roadmap or deployment plan for SOA, don't even think about it if there is no strategy in place. There is really no meaning of a roadmap if you have not defined a strategy that sets the direction of the entire roadmap. Defining roadmap is not such a complex thing but a roadmap that is going to drive all of SOA investments, programs and changes in the organizations, it better be based on strategic considerations.
• It is very common to see SOA programs to be heavily focused on integration platforms. Nothing wrong with it. However when considering a transformation view of the SOA program, there is a great opportunity to consider 'technology portfolio rationalization'. SOA must help enterprises simplify the enterprise landscape and hence such opportunities should be leveraged to reduce unwanted technology stack in the organization.
• I always believed and still stand by the view that there is nothing called 'SOA' solution or SOA portfolio. When there is SOA in the organization, it is nothing separate than existing elements of the enterprise eco-system including business applications, integration etc. SOA doesn't exist in isolation and has no life of its own. So it is extremely important to understand about the enterprise programs/initiatives that the concerned SOA program is tied to directly or indirectly in terms of outcomes. And if there is none, I will be little worried about the business case of the SOA program (and the money that is being put into it).
• As I mentioned in some of my previous blogs, BPM is likely to have more power to transform the organization than the SOA. In that light, when considering SOA, ensure that BPM is absolutely in the scope of the matter and is not left out as something to be looked into at a later point in time. That 'later' point in time never comes and even if it comes, it is never the same in the organization making it extremely difficult to get value out of SOA without it.
• We all need to understand that behind all good looking SOA roadmap, most likely there is going to be a huge task of legacy modernization/migration if SOA has to be a real thing in the organization. Given that, organization (and more importantly the SOA strategy consultants) need to clearly understand the landscape that will be impacted by SOA changes, nature of the change, readiness of the organization for these changes and finally the cost factors of these changes in the SOA roadmap. These are the important factors that make the SOA roadmap more real and credible.

In most of the cases that I have dealt with, I have been able to successfully add value to client's thinking process and quality of their decision making as far as SOA is concerned. So that's reason I believe this input will help larger SOA consulting community as well as organizations that are for ever in hurry to jump onto SOA, what ever that supposed to be.

SOA on its way out? Lets get ready for future

http://blogs.zdnet.com/service-oriented/?p=1168&tag=nl.e539 (Debate Rages over SOA's cloudy future - by Joe McKendrick)

I stumbled upon this article while reading some articles. As I read it, I heard a 'click' sound in my brain :-). My previous post of SOA's future, I speculated about fading of SOA's strongly hypothetical personality and come of age of BPM driven IT solutions.

As far as SOA is concerns, Joe makes precisely the same point of having more real forms of technical reforms like web-architecture, cloud computing etc. successful today while SOA as a whole still struggling to get into action for most of the businesses. As Joe says 'SOA is too hard to understand and does not lend itself to people just doing it'. I completely believe in it. I have heard lot of experts and practioners on SOA in last 4-5 years. By and large my opinion is that 70% of those drag the topic ultilately to web-services or similar technical topics. Rest of the 30% who tend to remain pure in terms of SOA as a concept also fail to bring realistic and implementation-level view-point on how IT can be transformed using SOA. So in nut-shell, SOA is loosing the differentiation it tried to create all these years but good thing is that because of this hype, some good technical innovation will happen that hopefully prove to be next-generation foundation when BPM takes over from SOA..We are alreadying seeing vendoring lowering their SOA pitch and slowly getting to BPM pitch in big manner...:-)

Story of the main-stream SOA

I’m calling it a story since it is yet to happen…more ambitious word for this will be ‘vision’. But given that ‘SOA’ and ‘vision’ have been beaten to death in last couple of years so let me continue with the story only. Key word in the title really is not the ‘story’ though..it is the ‘main-stream’ and soon you will see why. One of things in SOA that make me sick is the ‘real-ness’ of it (or rather lack of it). I personally feel that SOA as a concept is running out of steam to remain in the ‘hot seat’. There isn’t much new or different coming out from it than what has been spoken about thousands time already in difference styles and with different jargons. For that matter, I think ERP as a concept has done far better where in journey from speculative vision to physical realization (what so ever it has been, that really doesn’t matter) has been rather fast and it did change the shape of the industry to large extent. With SOA, industry seem to going on and on and on but like everything else, SOA will run out of the fuel sooner or later. If industry doesn’t something new in SOA which is the next level of life with SOA, it will not sustain. Skeptics are already ignoring it, even believers might drop the ball after a while. So what do we envision beyond this?

I think BPM is going to be a great savior for us. What I see happening is very sensible and natural in my view. SOA hype will diminish, BPM hype will gain strength. Though SOA hype today is far louder and taller than BPM but on the ground for sure BPM implementations are more real. When BPM will catch the steam, SOA will get a place where it really belongs to – a service enabling framework for BPM..:-)…so in that scenario, SOA will be a de-facto architectural construct in terms of standard architectural policies and design styles that will be utilized to make enterprise BPM happen. Given that BPM is really much closer to the business (closer than what SOA claims to be or could ever afford to be), it will be truly drive the change in the business solution designs. And when doing so, it will be able to leverage the appropriate stack of SOA enabled technology including EAI and B2B. That’s what will bring SOA in the mainstream. SOA will become the DNA of the Enterprise Architecture layers and will not need to be called out separately.

What it really means that our reference architecture of enterprise business automation will be truly complete where BPM will be in the driving seat and SOA will be the magic behind the machinery operating underneath. Today, BPM, SOA, EAI, B2B etc. all are reasonably fragmented and are trying to create the big picture for the enterprise in their small world..(what a contrast!)…in my story, this big pictures of the small worlds will slowly dissolve and the true big picture will emerge where all small words exist in integrated manner, in the place where they belong. And naturally, BPM will have the business impact measurements as the KPIs which will percolate into all layers beneath, be it SOA or ESB or EAI or B2B.

In my assessment, this has started happening already in pockets and it may not take more than another 2-3 years before it comes true in grand way.

Creating Sound and Credible Strategies for your Integration and SOA programs

I’m not really surprised to see the love-hate relationship between senior executives who own the integration portfolio and the ‘strategy consultants’ in my observation. Its love-hate dynamics because on one side where senior IT leadership strongly believes that a ‘strategic’ view is needed for creating the reliable roadmap for their initiatives, at the same time, there is really no reliable methods today to evaluate the appropriateness of the so called ‘strategy’ deliverables that consultants deliver. From the observation of the legacy in the enterprises I worked with, I find something very fundamental missing in those mysterious and high-end strategy documents: ‘Life’. Lack of life means that these strategies are more or less used as ‘initial requirements’ for certain programs/initiatives and as time progresses, strategies are not updated/maintained in line with changing state of the organization.

I have not seen too many of ‘good’ strategies in as far as integration/SOA is concerned for many large enterprises. So I thought I will put together a perspective on creating sound strategies for integration/SOA portfolio. To start with, I would like to share my view on what I found lacking in the strategy documents that I reviewed/audited for my clients:

• One of the big disappointment has been the ‘lose’ purpose and meaning of the strategy. Many of the strategy documents didn’t give me confidence if they had been developed being so particular about ‘strategy’ as such. So people who developed the strategy deliverables may have not paid attention what’s really needed in a strategy and might have limited the strategic view to just few principles/vision statements. It is quite evident when I see plethora of basic introduction to fundamental concepts like EAI/SOA/ESB/Architecture patterns etc in the strategy document. Will talk about it more in the next bullet.
• Next big issue I found in the strategy documents that really distracted the whole purpose of the strategy document. I find many of these strategy documents providing huge documentation around technical concepts, product capabilities etc and even the architecture blueprints in some of the cases. In my view, architecture blueprints and design guidelines need to be looked as separate elements and not mix them up in the strategy. Prime reason is that it dilutes both the purposes, strategy as well as architecture.
• Another key aspect that is critical for sound strategies is the clear understanding of the elements that drive and influence the strategies. I found it very difficult to figure out why a particular strategy was the ‘right’ strategy for the organization. Strategies need to be driven by the well defined drivers (like IT strategies, existing challenges) and the expected strategic results where number of strategic options need to be evaluated to arrive at a strategy that sounds ‘better fit’ for the organization.
• Almost in all the cases, I didn’t find any significant focus on the ‘strategy implementation’. Strategies were written mostly like ‘knowledge documents’ where implementation was not much of concern. So while strategies were interesting to read, my discussions with document owners revealed that organization really struggled to figure out how to implement these strategies and as result, most of the strategies kept sitting in the document only and find their way to real-life.
• Again, almost in all cases, there was no consideration of impact of these strategies on the enterprise and no aspects of ‘readiness’ of the organization to be able to roll out these strategies. I don’t find such strategies very ‘real’. Point of strategy is not to gamble but to strengthen the chances of success.

List doesn’t end here but let me stop here. If I were to suggest how integration strategies need to created for the enterprise, here is what I will recommend to be considered in the strategy formulation based on my experience:

• Team that is creating the strategy should not look at the strategy articulation as a template that need to be filled. If that is how it is being done, that’s first sign of the disaster. Team needs to clearly understand the ‘strategy engineering’ process where set of information (like vision, issues, expected outcomes etc.) are taken as input, processes and based on certain hypothesis, strategy formulation needs to happen.
• As I said, strategy starts with getting clarity into what is driving the strategy. It helps defines the goals that need to be put forward as a ‘result expectation’ for the strategy. For example, enterprise could say that one of the key goals of the strategy should be to reduce the our TCO by 10% in 12 months.
• Team needs to consider the major influencing factors for the strategies that could be recommended. To arrive at such factors, SWOT analysis of the integration portfolio is must. Further to that, team should consider the possible scenarios that the strategy implementation could be facing and from there analysis must bring out how these strategies are anticipated to perform in those scenarios. This will help kicking out the strategies that sound exciting but can’t perform to the results in most realistic scenarios.
• Before strategic options are identified, we must identify all the strategy areas/themes where strategies need to be built. For example, for integration portfolio, it could be Architecture/Technology, Service Delivery model, Sourcing model etc.
• While formulating the strategies, there are 3 elements that need to play a role in defining a credible strategy. First: Input – something that is given and cannot be changed. Second: choices – to meet the objectives with what is given, what strategic options are available. Third : Action – how selected strategies need to be deployed.
• Once set of strategies are defined, a prioritization needs to happen based on the feasibility. Input of scenario performance of the strategies will be a good input.
• It is very important to analyze and details out the impact of the strategies on the exiting eco-system of the organization. That makes the strategies real and practical.

Unlike technology and architecture, unfortunately we can’t have one standard solution for strategies. That makes it very vulnerable for enterprises in terms of their ability to judge a strategy. But I also believe that process of strategy development itself in many ways a revealing and learning experience both for the client and the consultants. Hence in area like integration where strategy may not have been playing so much critical role so far, it must be taken very seriously as move in the next-generation enterprises. I would keen to know how my experience aligns to other practioners in field. So drop your view-points on this topic if you are here.

"What Next" for Integration Competency Centers (ICC)? - Part 2

In my last blog post of this series, I talked about the next-generation highlights of the ICC. First one in the list says: Next generation competency centers will make it lot easier to execute and manage the changes than how it is today. That will transform the role of 'change' from 'threat' to 'opportunity'.

Reason why I see it coming because I see today ‘ability to change’ to be a major roadblock in the enterprises irrespective of the area we talk about (technology, infrastructure, processes, standards etc.) and irrespective of the nature of the change (consolidate, standardize, migrate, optimize etc.). It means that unless we unlock the secret of managing the change better and make it easier to change, we are going to get poor results in almost all scenario. Let me take a real-life example out of my engagements to help understand this point.

Here is this mega enterprise xyz that respects technology leadership and strongly believes that staying ahead in the IT leadership can make them absolutely winner in terms of differentiating in the market. So this enterprise is all up for mega investment into end-to-end transformation of their integration landscape. They got best of the technology lined up, they got best of the consultants lined up and got best of their leaders in the row to deliver this transformation. So as one can see, it involved technology platform change, change in the way architecture is being implemented, change in operational and engagement processes, change in terms of their organizational structure and what not. Organization muddled with it for more than 6 months only to realize that it is not going anywhere. Why that is the case when funding is given, best consultants are working out their brains and top management sponsorship is also there? It was not because changes being done were inappropriate or invalid. It was actually because doing change was so difficult in the organization and they were just not prepared to do it in the scale it demanded. Talking more specifically:

Requirements change scenario – requirements change here was nightmare. Every time a requirements changes, there is huge process of getting the change request approved and subsequently, for every requirements change, huge round of regression testing (to ensure no damage has happened) will be done. This all made every change difficult. There were two key things tried here to make life better. First, stakeholder analysis was carried out along with responsibility map to rationalize the change approval process. Apparently there were too many folks involved in decision making and no one actually owned up the decision and hence every one really just passed the buck or just played safe. Through this analysis, few stakeholders were taken out of the loop and decision making has been simplified by empowering few roles. Now with sufficient and necessary information at hand, a handful set of folks could quickly make a decision on approval of the change. Secondly, a prioritization scheme was developed to make regression testing somewhat practical. Business stakeholders now scan through the business use cases and identify the most critical cases for regression. Rest were simply reviewed by business analysts and architects and their signoff was used as basis to approve the change in production. Through this process, cost of regressing testing of the change was brought down to 40% of the original cost, needless to say whole hassle of test management was saved as well.

Process change scenario – changing any process in this organization is a strict no-no. why? Because everyone of comfortable doing what they do and they don’t believe anything needs to improve. So any process change initiative dies down either at the recommendation level or is proven to deliver bad results by deliberate attempts of the staff members. Now that’s really really scary because it tell me that this organization can never improve. When we analyzed the problem , we figured out two important things. One that most of the time when change is introduced in this organization, people have no clue why that change is being done. Second, for any change, large part of the people involved in the change believe that even if they don’t accept the change, nothing is going to happen, things will move on. To make the process change easier, these two problems were addressed. It was mandated that for every process change, right from top to bottom, every stakeholder has to be made aware about the change drivers and criticality of that change for the organization and for their specific roles. This also gave opportunity to the organization to address any operational concern at individual role level before change is physically rolled out. Second part of the solution was to bring accountability into each role toward this change so that everyone knows the impact on them if they didn’t implement the change effectively. Now that can be argued to be a ‘threat’ based philosophy but it actually worked.

And that’s not just one off case. I have seen several of those examples where similar story has been repeated in slightly different color and shape. So moral of the story is that ICC of tomorrow need to innovate methods and means to make it easier to deal with the changes. Further to it actually innovate the ‘changeability’ to the extent that it can be leveraged as opportunity to make continuous improvements towards business objectives. Having said that, there are two key questions that must cross our mind when we talk about it: a) how do we really do it b) What cost does this come with. We will focus on on "how do we really do it" part here.

How do we really do it?
Change enablement is not easy. This is all about having deeper and wider understanding of the change patterns and subsequently adjust the retarding elements from the change mechanics. Philosophy is simple, change is devil because it comes with unwanted cost and organizations don’t have capability to manage the impact of the change. So if we are able to make the changer easier, cheaper and low-risk, then why not change? We in Infosys have a well-defined framework that we offer to our clients to inspect the change mechanics in the organization, spot the retarding elements and look at options to handle the change better. Some of the general strategies that can be used are:

• Self-service capabilities for the solution development and maintenance process so that a lean team can easily handle the portfolio responsibilities. This self-service capability is not only for the software engineering process but also for the other processes that involve decision making, analysis and interactions across multiple stakeholders. For software engineering, self-service capability allows application teams to develop normal integration scenario by themselves by using a simple self-service enabled integration workbench. As name suggests, self-service capability allows application teams/business team to configure integration scenario without needing to have knowledge of underlying integration products/platform. Similarly, self-service capability allows business units to have certain information / intelligence about the integration by themselves without needing to depend on the integration team. A good example of this is an EAI feasibility analysis and Order of Magnitude cost calculations. For both of these, business units can be provided with an online framework that allows them to feed in input available to them (non-technical) and get the sense of outcome (either a go-no go recommendation for EAI or the OOM figure) that allows them to do first level of decision making. This will not only make the decision making process faster but also helps cutting down the effort required in ICC to manage such interactions.
• Change consolidation across the enterprise before changes are applied so that investment into changes are optimized and prioritization of changes taken enterprise-wide value considerations. My experience with large number of enterprises tells that very often money spent on various changes (either in software or vendors or methods or on processes etc.) is not trivial and most of the time, enterprises have no visibility of the enterprise-view of the changes. So for example, there has been so many cases where different units of the same enterprises have been evaluating different products for the same purpose (integration in our case) without having visibility of what other units are doing. So they end up spending money of consultants, their own staff, infrastructure and surprisingly in many cases have ended up have different product selected (so there goes the possibility of license optimization through economy of scale).
• Lose coupling of the changes to reduce the spread of impact (localization) by means of meta data layer. Most of the time, main change is not difficult but what scares the organization are various strings attached to change causing second level of change due to dependencies, then third level of change and so on and so forth. This chain of impact actually sucks up money big time and make the change a really painful process. By carefully analyzing this chain of impact (and hence dependencies), lose coupling can be built to localize the impact of the change. In the software engineering space, smart use of meta-data layer can really help to build loosely coupled parts of the software ecosystem and thus breaking the long chain of impact. This concept is not new but to my surprise, maturity of adoption and implementation for the same has been really poor as I see it. One good example of this decoupling is configuration driven change. In the design, if we have provision to make the execution level change or solution behavior change simply by changing a configuration parameter, that will eliminate the need of hand coding, retesting and redeployment and thus making is easy to change by simply dealing with the configuration parameters.
• Leveraging the possibility of automatic change propagation and thus reducing the manual effort (of doing it first time and reworking the manual mistakes later on). Previous point suggest that chain of impact really drives the cost of change in many cases. Where we are able to break the chain, its fine but if chain of impact is unavoidable, next weapon against it will be automation of the change propagation. Where ever possible, an automation framework should be built to be able to create the modifications/alterations based on original change using automation rules/scenario intelligence and change algorithms. This will again help reduce the cost of change and increase the speed of change. A good example of this is automated build and deployment process. As soon as software baseline changes, a click of a button should allow to package the entire solution and deploy in the final destination without needing to manually do anything. Similarly, in an advance development workbench scenario, a change in design can be easily propagate to automatic creation of meta-data and in some case the actual code as well.
• Build intelligent change analytics to get full understanding of the change dependencies in order to reduce the hidden costs (and hence overshooting of budgets). From previous two points, it is very obvious that chain of impact and dependencies are important elements that drive the cost the complexities associated with the change. However, if those are not known upfront, it poses serious risk to the success of the change initiative/process. The late realization of chain impacts could cause inability to sustain the change or drag the larger part of the program to deal with the newly emerged impacts. Intelligence change analytics provide the clear impact view upfront and thus allows stakeholders to make informed decision about the approval of the change. At the same time, it also gives opportunity to investigate the chain of impacts/dependencies and identifying innovative mechanisms to deal with the change.

I hope this part of the story would have brought in some insight into thinking of next-generation ICC from ‘change’ perspective…btw, few call it agility. Doesn’t matter what we call it. End results matter. So you have any take on this perspective, I’ll be glad to hear about it and discuss. It might help me evolve the next-generation ICC story for everyone’s benefit. Watch out for the next part of the blog soon on "High degree of collaboration of the ICC across stakeholders" as Part 3 of the blog.

'What Next' for Integration Competency Centers? - Part 1

Factually, that’s the not the most popular question being asked by my clients so far. Potential reason could be that most of the enterprises are still catching up to establish an operational competency center capability. ‘What next’ has been the idea that I have been tossing every year in my mind since last 8 years as far as evolution of competency center is concerned. And I’m sure same had been cases for many more analyst and consultants across the globe. This global appetite to discover ‘what next’ and to materialize it in real life has helped the industry to progressively evolve a concept like Integration Competency Center. Result is that while 8 years back we were exploring the concepts of ICC together with our clients, 5 year back we were driving our clients into ICC and some of our clients were driving challenging ICC designs from us and in recent 2-3 years to our deep satisfaction clients have been demanding transformation to superior ICC designs and we are stretching our abilities/innovation to meet the demands. I believe that global economic dynamics that we are seeing today will soon start pushing the enterprises in medium to long term and in turn driving consultant like us toward ‘what next’ very seriously. So that’s about why I’m writing about it. I will be running a series of blogs on this topic to cover the end-to-end story over a period of time.

Let us come back to this ‘what next’ for Integration competency Centers. Integration competency centers that exist today are varied in their service capacity as well as organizational positioning. These competency centers are somewhat centralized body of service groups with a charter of providing services required for enterprise integration. This group has good subject matter and technology expertise to be able to service enterprise integration specific requirements. Most of the basic processes and guidelines are in place that are used by this factory (another way of looking at ICC) to operationalize the integration life-cycle functions. These competency centers are able to meet the scale and demand of business with good service level performance. So what’s up for these competency centers as next big thing that they are going to transform to?

So as I see, there are set of next-generation views on the horizon:

1. Next generation competency centers will make it lot easier to execute and manage the changes than how it is today. That will transform the role of 'change' from 'threat' to 'opportunity'.
2. High degree of collaboration of the ICC across stakeholders that allows more transparency in the engagement and leads to co-creation of methods of delivery/operation of ICC with stakeholders like business units, application teams etc.
3. Though current ICCs are operational but there is good likelihood of presence of what I call 'eco-system fat' that makes the entire ICC as a organizational system slower, less effective and costly to improve. With current acute economical cost pressures, a system like ICC will need to reduce this fat significantly by adopting lean methods in terms of people, processes, systems etc.
4. Another important shift that can be bring into ICC is clear identification of value added functions and 'operational' functions. This will help, one to automate, standardize and accelerate the operational functions; second it will give opportunity to channel the investments, thought leadership and innovation effort more toward value added functions. One of the strongest feature of such ICC will be availability of 'self-service' capabilities in many facets of the ICC
5. Many of the ICCs don't leverage high-maturity sourcing models. Next-generation ICCs have opportunity to create strong sourcing model to leverage the strengths of SI vendors and drive focus of in-house staff toward more value added contribution. In essence, engagement model of sourcing will shift to 'outcome driven' and not 'activity-driven'.
6. Gainful utilization of the social networking systems like Facebook, LinkedIn, Blogs etc. has huge potential to change the face of knowledge management in the ICC.
7. 'First-time Right' effectiveness will become important to ensure that wastage in rework and 'fixing' that should not have been in very first place becomes an important metrics in the ICC.

Now, while these changes might be exciting, they are not very easy to come by. I will start getting into details of these in subsequent blogs. Meanwhile, if readers believe in another other next-generation changes for ICC, I will be glad to hear about that and possibly include it in my subsequent blogs.