The most interesting people are not the ones that tap you on the shoulder and say "well done", but the ones that challenge the whole fundament of your ideas. Following up on my blog post "Divide and conquer to solve the business-IT disconnect problem", @thesiteman challenges my post and asks:
My question to him is "How come we're not asking IT to change?" Why is that we're asking them to stay in their silo? Isn't that exactly what enterprise 2.0 is trying to eradicate? If we're look at the business side to be agile why are we not requiring the same from IT? Why do we think that IT can not be flexible?
Well, I can only say that @thesiteman is completely right. What we would like to see is that the corporate IT department is as flexible and as agile as the business side. Why? For the fundamental reason that IT is there in the first place to ENABLE the business to do their job, preferably in a faster, cheaper and perhaps different way than without IT. That is a very important point that a lot of people seem to forget.
In defense of the corporate IT department
Taking in account one of the challenges that Social Business Design has identified, I still stand with my post:
New trends, no matter how revolutionary, must still overcome the limitations of the past before becoming fully adopted. In organizations, legacy systems and platforms, cultural elements, and governance requirements all work to limit the willingness to experiment and innovate. In order to meet these looming challenges, businesses need to fully understand the legacy structures in place within an organization and determine how to leverage these structures while implementing new processes to improve results.
So, while the ideal scenario is that the corporate IT department is very flexible and agile, the CIO has certain challenges to overcome first. Think about large legacy systems (e.g. old mainframes), multiple ERP instances across several business units (if you are lucky they are from the same vendor), a plethora of vendors and platforms, etc. One thing I want to emphasize again and again to frustrated business unit leaders: this is NOT because corporate IT department leads are not doing a good job. This situation happens naturally in almost every large global company that is the result of mergers and acquisitions and that is old enough to drag legacy systems with it. Knowing that there are often hundreds of man-years and tens of millions of investments in there, you are not talking about a greenfield scenario.
If you are the CIO of a large global company that suffers from the above scenario, you will consolidate the different core ERP systems, you will reduce platforms and you will define a uniform IT strategy that aligns all efforts, architecture and development. Not because that is so much fun (although I know people that utterly enjoy this), but you need to have these things figured out before you can fully support the business in their operations.
To give an example: if you are a large group company and each of the five business units have their own ERP system (not all the same vendor), how quickly do you think that you can get insight in what happens in the group? Most likely you'll have to wait a couple of weeks to get the numbers from the previous quarter because they all need to run reports, align the results and consolidate it. In nowadays' economy, what you really want is real-time integrated business intelligence. With a snap of your finger, you want to get insight in what happens now, not what happened 2 months ago.
Reconnecting Business with IT
Obviously, the show must go on. The company must bring new products to the market, the sales force must sell more and costs must be reduced. Since we can't stop the operations of the company for three years, we need to find a temporary solution that allows gradual change of the IT landscape while keep on delivering value-added services to the business units.
In my previous post I have mainly focused on the reason why we should transform the IT department from a solutions provider to a solutions enabler, without going deeper in how we are going to reconnect the two. We need an approach for our IT and business architecture that allows evolutionary change in both the technical side of the organisation, as well as supporting changing culture and processes.
The way we are going to reconnect the business with the corporate IT department is a very well known problem pattern identified in the Russian problem solving thought framework TRIZ. Principle 24 tackles the problem where two surfaces are meeting with each other, causing an undesirable (or harmful) situation. TRIZ suggests introducing an intermediary material between the two surfaces. Think about shaving: you're using shaving soap as an intermediary between your skin and the blades to smoothen the experience.
If we consider the business units as one surface and the corporate IT department as another surface, what will the intermediary material be?
Allowing gradual change
Besides breaking down internal silos, corporate networks must incorporate previously external nodes as contributing participants as well. The technology required to support this network must operate as a platform delivering what is necessary and relevant for nodes to perform and progress towards business goals. (Social Business Design for Workforce Collaboration)
This platform, or the "intermediary material" as described in TRIZ, will be implemented along the principles of Service-Oriented Architecture (SOA). The huge data silos that are present in the company contain a vast amount of data, together with the corresponding business logic for safeguarding data consistency. However, the problem is that we don't get enough value out of these systems, so let's open up these systems through services or APIs. The end-goal is of course to optimally support the business user in their daily work, so the user-centric applications (like an iPhone app, a customised SharePoint page, a widget in Jive SBS, ...) will tap into the services or APIs from the back-end systems.
In order to keep this all a bit manageable, we will need to take care of the following:
- Gradually disconnect the user-facing applications from the back-end data silos and introduce a middleware layer that acts as the hub between the user-facing applications and the back-end data silos.
- Anticipate changing processes: using Business Process Management systems we can dynamically (re)configure processes between user-facing applications and back-end data silos
- Focus on identity management and security: you will need a smart identity management solution for Single-Sign On across all the applications and a strong security model to control access to your precious data services / APIs
The added benefit that this approach gives us, is the fact that we don't need an overnight big bang implementation. By ensuring that there is no tight integration of user-facing applications, business processes and back-end data systems, we have now an IT landscape that allows gradual change in order to reach one day the much-desired "agile enterprise" that we are all dreaming of...

Lee. it’s not just M&A, but also IT who have reacted quickly and thrown up an application to support a business problem or Shadow IT grown out of a division/department - again to support a business problem that has gone from short term to business critical. We can’t complain about this - at the time it was right for the business.
More often than not, its quicker to do this than change the mainframe or core ERP/CRM apps and comply with the rigorous release cycles of 3, 6 and 9 months – with stacks of changes building up to go into the next release.
Additionally and as a result of this, we are not typically starting with a blank canvass. As the old joke goes - it only took God 7 days to build the world as he didn't have a user base!
We don't often have the luxury of a Greenfield site. We do have to piece things together - if we did I don't think this problem would exist or perhaps it would not be as bad.
I also don't believe the pace of change between business & IT will ever be aligned, one will always play catch up to the other and no guesses as to which one will make the demands and who will have to play catch-up! So with this in mind, we have to find a new way to help smooth the way between the two differing requirements.