Posted on September 10, 2013 by

Bridging the IT Gap

Over the last 10 years and possibly longer there has been a goal of achieving business and IT alignment.  In some respects this has become a core comptency in some jobs which are advertised.

As someone who works in technology I always ask why?

Technology now plays a significant part in our lives

The intent of technology was to make our lives easier and help us achieve jobs much more efficiently. However as technology has become more advanced it seems to have become its own organisation, within an organisation. You start to hear technology teams use terms such as “the business“.

Management also look at technology as the nerdy people who make things work, as long as they are happy, we are happy.

However ask the management team what they are paying for in terms of IT solutions and the answer will be “ask the IT people”.  To me this seems crazy as this goes against the intent of technology.

We can’t blame the technology when we make mistakes.

What has caused this divide and how can we resolve this and put the power of IT back in the hands of the stakeholders, but also bring  IT back into the wider organisation.

 All in a name

Spend any time in an operational environment and you start to spot something quite strange. The various operational staff actually know more about the technology than the people in IT.

In fact they use the same terms as technology.

Technology is a useful servant but a dangerous master.

You will hear applications referred to by their physical name, yet no one really knows what the applications do. When we have a small amount of applications this is not an issue, however when the inventory grows, we start to see application rationalisation initiatives appearing all over the organisation.

Is hard to understand what has caused this issue.

Could it be down to the IT teams referring to these terms when engaging with the rest of the organisation, or could it be the result of the language which is used by management.

Regardless of the source of the problem, this approach starts to create black boxes.

hidden workings

As time passes, staff leave the organisation and the knowledge of the application/s generally leaves with them. Capacity planning becomes complex and any type of transformation becomes almost like a military exercise, due to the fear of change impacts to the wider organisation.

Change creates fear, and technology creates change. Sadly, most people don’t behave very well when they are afraid.

The sad thing is even when transformation occurs, we still refer to the applications by their physical name and probably will go through the same pain, in the future.

 To create something genuinely new, you have to start again. With great intent you disconnect from the past.

How can we change this and is it time to take a new approach.

Putting it back into business terms

The first task for IT is to start cataloguing the applications by what they do and mapping these to the various physical applications that perform those capabilities.

This can be a complex task but there is a quick solution. The quickest option is to name all the applications after the business capability model (where possible).

Revised Systems12

At this stage the goal is to map what they do, not how they are implemented i.e. mainframes or ERP applications.

This approach also helps when you have a significant number of user defined applications, such as access databases or spreadsheets which have been created.

Through this approach we can map core and user defined applications and easily identify where we have duplicate capabilities. It is worth noting at a certain level you will map the application services which each application offers.

These should still be in business terms and are likely to be seen in the implementation model (part of the mapping from the application catalogue) and are used in the various process models the business will document.

 Line of sight

Over time reporting will improve and we will start to understand which activities are being supported by services and the applications which realise these services.

servicemapping

As content grows we will also start to understand the technology footprint across the wider organisation, due to relationships across the wider business model.  These relationships enable us to ask all sorts of technology and business questions which previously were not possible:

  • Which applications support what business capabilities
  • How many applications provide a specific capabilitiy
  • Which applications provide the same service
  • Which applications support the same business process
  • Which locations does an application support
  • What is the cost of running an application and how many business units fund it
  • How many user defined applications provide the same capabilities as the core applications

The reporting opportunities become endless and the ability to spot technology duplication improves dramatically. Finally a bridge starts to form between the business and IT, due to a common language.

The ‘So What” moment

1026653_50453137As we move into the world of the eco system, the need to understand what technology is available and where it is used is becoming crucial.

Senior management need to have confidence that they are investing in the right solutions and are able to respond to either external or internal change, quickly but efficiently.

Moving away from traditional application naming ensures that we can start to not only trace where applications are deployed but also easily spot duplications. Crucially we also start to build a bridge between the business and IT worlds, which starts to bring IT back into the wider organisation. This helps remove all the previous barriers which have stopped IT being a trusted partner in the past.

These are clearly valid benefits for moving to this approach but as always there are a few more:

  • Capacity Planning: much easier to determine capacity due to application interactions made visible.  Plus a greater alignment to process ensures throughput rates can be determined.
  • Communication: business and IT communication is improved due to a common language. Also vendor and third party communication is improved due to the adoption of application capability terminology.
  • Rationalisation: duplicate core and user defined applications are much easier to identify due to capability naming convention.
  • Support: failures or errors, and their source are much easier to resolve due to the ability to communicate the capability impacted vs the overall application name.
  • Modelling: application catalogues can be provided to support business modelling initiatives. Content is reused and overtime application reporting will become richer.
  • Approvals: senior management are able to easily sign off technology changes due to information provided in business terms.
  • Cost: applications costs and  usage are easily determined
  • Impact analysis: identification of problems which are a result of either a proposed or enforced change improves. This is due to application naming and consistent use across process models i.e. full line of sight
  • Testing and Deployment: greater success from testing can be achieved due to capability features being tested vs the traditional black box. Also using business terms when describing interfaces ensures that payloads and interactions between application capabilities can be identified and tested.
  • Transparency: increased clarity of application usage.  This provides comfort to audit but also helps determine which applications are considered high priority, based on their use i.e. process or location specific.
  • Management: application content is easier to manage and can be maintained in a variety of ways i.e. technical reference model within the IT team.
  • Black-box removal: inner workings of applications are exposed (application capability interactions) which removes the mystery which previously existed.

The list of benefits are endless but these examples clearly demonstrate why a move to this approach is needed.

Technology was created to make our lives easier, as more advancements are made it is clear we will be leveraging it even more. It is crucial that we are able to not only understand how to leverage it to provide new customer experiences, but also manage any changes we make in the business enviornment.

Changing terminology not only makes applications more understood, it also starts to bring the technology team back into the wider organisation.  This ensures that a bridge is built between the business and IT, and a trust is restored.  It is this trust which is going to be crucial as technology starts to play a bigger part in our lives.

Sources:

  1. Jonathan Ive: Design Quotes
  2. Tim Berners-Lee, Daniel H Wilson & Christian Lous Lange: Technology Quotes