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…
This post originally appeared on the Headshift blog.
Good advice.
Agility should involve a major transformation effort, as there’s not much about major transformations that are agile. The key is to understand that different areas of the business evolve at different paces, typically the UI and backend, and then decouple them so that they can evolve at their own pace
Have you put any thoughts into how to plan / strategize in this environment? The traditional Zachman / TOGAF approach doesn’t seem relevant, no matter how incremental you make the approach, and we still need some way of communicating to the business that we’re working toward their overall goals.
r.
PEG
@Peter really nice article you shared there!
Coming towards your second point, one of the difficulties of the approach described in the blog post is that it does not add direct business value to the company and thus hard to justify the cost and time spend on it. Yes, it will save us in the mid-long/long-term, but won’t give tomorrow a new feature.
Having seen several large companies where due to the business pressure, the focus was rather on developing new apps with new functionality, rather than taking a step back and wondering whether we’re doing it in the right way.
An approach that I’ve found quite successful in one of my engagements was to just start 1 not-too-big/not-too-critical project according to this approach and thus putting down the right infrastructure/environment in place. Then take on step by step new apps, changing apps and old apps. It’s a long process, but believe that it wil deliver faster results.
@Lee
Ta, glad you liked it.
I think the business value of an approach like the one you mention is to engage around workflows and business decisions, rather than IT assets. It’s a variation of the old 80-20 rule: find the 20% of the decisions/workflows that will have the greatest impact if automated, and mash them up, and then do the next 20%, and so on. This way you’re delivering early and incremental business value, rather than and IT asset.
I find that focusing on IT assets to be counter productive these days. In the UI space we need to move to a model where everything is multi-channel by default, and on the back-end we need to factor in cost-crushing tools like SaaS. As a friend likes to say, we have more than enough tools and technology to solve the problems infront of us. Pause, reflect, and then focus on delivering incremental business outcomes.
r.
PEG