Potential Pitfalls in Technology-Enabled Business Transformations

In my experience, when Enterprises perform Business Transformation design exercises where the solution is to be enabled or underpinned by technology, a core list of the same potential pitfalls are regularly encountered. It would be interesting to see whether others come across the same types as well, so here are a few examples of what I always tend to come across:-

Potential Pitfall	Ways to Avoid It
Lack of clear business justification for all IT decisions	Retain a clear audit trail for Design Rationale through a fit-for-purpose framework that leads from Design Objectives->Design Rationale->Business case->Executive sign-off.
“Package-Think”	These exercises are almost always about more than a package, there are almost always other pieces required, needing the correct sequence of SMEs to cover all, not just the biggest and highest profile one.
Technology instead of Architecture	A solution architecture approach (rather than a technology beauty parade) is the only way to consider the implications on the design and technology decisions, and therefore deliver the best-fit technology portfolio for the solution with the most accurate and informed business case. Performing your 'as-is' analysis to surface the constraints and opportunities you have, and use of external SMEs for what’s possible.
Too Much Detail Too Early	Don't get bogged down in analysis for analysis sake in the early stages. Get enough information to understand enough to make a decision rather than know everything in detail. An 80/20 approach will identify the hot-spots. Focus down on areas that will deliver the most benefit. Move to the detail when the way forward has been agreed.
Focusing on the First Step	A balance of ‘art of the possible’ with ‘what needs to be fixed’ is necessary to design a solution which meets the requirements, but also delivers the business case through its life. Generally this requires that as well as agreeing objectives and design principles, the early phases also need to collect the hypotheses on what needs to be fixed, whilst of course doing the necessary identification of the 'as-is'.
Wish List	There is always a great temptation to use a transformation design exercise as a means to fix bug-bears which can colour / mitigate the value of the transformation. These quite likely need to be recorded, but the process must manage them so they don’t dominate. Not everyone likes the word 'strategic', but here it is important.
Reinventing the Wheel	Use best-practice 'off-the-shelf' processes as a design input, and try to stay vanilla (minimising customisation to where it's really needed for good business reasons that can't be standardised) to minimise IT costs and maximise efficiencies.
Waterfall	To avoid a sequential ‘waterfall’ where the outputs of one team become simply the input to another (with the inadequacies & risks that carries). The process needs to be iterative to repeatedly test assumptions, consider implications & and refine the design.
Lack of joined up working between IT and the Business	The work-streams need to work together to mutually inform each other, and to generate the cross-functional buy-in. Of course the IT solution will not drive the to-be business processes and operating model, but it will be an influence on them - unless you believe that what is available and what is achievable doesn't influence what is feasible and deliverable.

Technorati Tags: Business Transformation Enterprise IT Business-IT Alignment IT Excellence Solution Architecture Enterprise Architecture EA

Dare I mention the word 'Applistructure' ...

I'm not sure who ever came up with the word 'applistructure', but I think it may just be one of the worst IT jargon words ever created. I have never been able to mention it to colleagues or clients without at least raising a smirk, or more likely inducing outright ridicule.

But actually, tempted as I have always been to disregard it as some believe we should, I do actually think the concept behind the silly word is rather important. In particular, for enterprise IT departments, I believe it represents something they should be thinking very closely about - in that it represents a significant change in the capabilities, divisions, skills and focus they need moving forward.

The idea is that 'applistructure' is the blurring of the line between enterprise applications and software infrastructure, in that, rather than specific silos of applications sitting on top of the shared software and hardware infrastructures, the enterprise applications themselves become part of the shared capabilities or resources which together are almost akin to infrastructures, at a higher level. This is to say that the application components (e.g. ERP modules, CRM modules, SCM modules etc) 'join up' with the software infrastructure that underpins them (e.g. app servers, integration buses, data management hubs, portal platforms etc) to form a higher level infrastructure that businesses can exploit, share and reuse.

Before your natural cynicism causes you to see red, let me explain why I think this is important.

Traditionally the lines between the functional people and the technology people in IT have been fairly firm, particularly in the packaged applications space. Both Oracle and SAP for example have very distinct teams, often with totally separate structures, both in their clients, but actually also within the software companies themselves. Although some separation is necessary for specialisation, the chasm that tended to emerge between the two sides (I believe) caused real quantitative and qualitative issues.

I believe that the 'reunification' of functional and technical IT viewpoint (whether you call it 'applistructure' or something else) is not a bad thing. For some IT departments, it will help move them away from purely obsessing about technology, and onto the business value from the architectural combination of the two. And for others, it helps force the functional IT people to not ignore the technology, and hopefully therefore to not carry on creating solutions in isolation of (or in spite of) the silo'd, duplicated or deprecated technology involved.

Of course this is closely related to the concept of SOA. As such, 'applistructure' implies that your SOA technology platforms need to managed and designed on the terms of your applications and data . No more separation considering interfacing as being separate from applications. In SOA you need a common unified and mutually-informed approach to applications, integration, data management, user interface etc. The decoupling requires this.

The concept of 'applistructure' also helps combat the plague of pseudo-value that has come into being recently, where software infrastructure platforms try and claim value propositions of applications they support. Quite frankly I've often in the past got quite irritated when software infrastructure vendors pitch their platform technology as directly providing business benefit even though it is not a solution. You know the kind that claims "our competitive differentiator is business agility" when all their technology does is provide a means to move data with less mouse clicks. I've always found this bizarre, as though the company that makes the tyres for my car would claim that their competitive differentiator is my timeliness for meetings, when what their product really does is at most allow me to go round corners slightly faster. Of course, it's not the tool, it's how its used with regard to specific solutions that is what drives business value. And by bundling up both solution-specifics and non-specific software under a common reusable architecture, the concept has far more leverage that the disjointed combination of applications and the various types of middleware did before.

So of course, one man's infrastructure is another man's application. But moving the average perception of what the platform is up, and moving the average level of concentration towards application of these higher levels of platform, may well be a very healthy exercise. Even if the word is still stupid...

Technorati Tags: Applistructure Service-Oriented Service Architecture SOA Enterprise IT ESB BPM