By Sven Vollbehr, SAP Certified LEAD Business & Enterprise Architect, SKF; Speaker at The Open Group Paris 2016
Recently, The Open Group released a new open standard IT operating model and reference architecture called IT4IT™. They billed it as the answer to “How to run IT like a business.” At the same time, our Enterprise Architecture team at SKF was supporting the rollout of a major SAP initiative. To be successful in this initiative we became convinced that we must also simultaneously transform the way IT worked with the business to provide value.
Through this transformation, we aligned business strategy and IT operational governing activities through a pragmatic way to capture business demand and deliver services to the business that maintained traceability and alignment with the original demand. This article provides some valuable lessons that we learned on our transformation journey that we believe will help you re-orient IT to focus on business value, to structure its operating model, and to look into ways to gain additional growth.
Step 1: Agree upon the IT Business Model
It is a broadly recognised – if not necessarily discussed – fact that IT organisations are experienced in developing and using IT operating models without necessarily knowing what value that the business within which they operate require from them. There is far too often the scenario that IT teams, within their well-planned out, best practice, quality assured activities, inherently hope that what is delivered is what the business themselves hoped for.
Many IT departments comprise of people predominantly from a technical background and are not necessarily schooled in business competencies which would allow them to reorient their activities to align with a business perspective. This is not a criticism, but simply a fact of how IT teams have traditionally been positioned in most organisations with respect to their purpose, structure and most importantly their behaviour and stakeholder relationships.
The viewpoint makes all the difference. While we believe the IT4IT Value Chain has a genuine place within the strategy of an IT organisation, we have identified that it is only a useful tenet for SKF if our IT Value Proposition is determined first; in this way the Value Chain supports the type of IT organisation we want to be, the roles we perform and the services we deliver, all undertaken within the fullest business context of the organisation. As it stands today, the IT4IT Value Chain puts more focus on IT operations than strategy. This is not necessarily incorrect, but does only represent one viewpoint.
Looking at how to run IT like a business from the customer viewpoint should start with different questions. We were required to fundamentally address these blind spots, to align IT in such a way that it reflected the broader (essentially non-IT) organisation and their transformation ambition. For our transformation, our chosen approach was aimed at ensuring the end-to-end structure and execution of our IT operational delivery would be fully aligned with business strategy and outcomes. We had a very specific IT Value Proposition in mind which determined the capabilities and structures we required.
With IT4IT, the IT Value Proposition is an implicit one which dictates many of the other aspects within the framework including the organisational setup. With our Value Proposition determined with respect to the type of IT organisation we were – and more importantly wanted to become – we concluded that a different organisational setup was required for our specific requirements, thereby driving the creation of a variation to the prescribed IT4IT Value Chain.

(Source: Moving from the back office to the front lines. CIO insights from the Global C-suite Study. IBM Institute for Business Value, November 2013.)
Building on these fundamentals, we can then define – with the business – targets for our transformation to deliver on the stated business outcomes. This would require the necessary organizational structure to be established both in classic hierarchical and associative terms but also in terms of shared and inter-related functions and accountabilities, all of which are aligned to shared business outcomes (not siloed technological outputs).
Step 2: Take Structured Approach to support the IT Operating Model
As an Enterprise Architect working in the IT Management, you have the heavy task of aligning between different organisational silos as well as architectural framework, and industry standards and best practises. Whilst each existing framework and standard has its own intended points of focus, they all share the same restrictive principle i.e. they take a “toolbox” approach where the more content you have in your framework, the more value you provide to the architecture practitioners – but only in and of the particular framework and do not take into account the need to provide insight into how they connect to the broader environment. It is therefore difficult for practitioners to implement the frameworks, understand how to integrate between multiple frameworks or what to prioritize for the benefit of the organisation. Such frustrations do not lend themselves to focusing on delivering business value.
The core value of IT4IT is in the fact that it forces you to think in terms of the value the IT Operating Model is set to deliver. Combined with an explicit IT Value Proposition, this becomes a very efficient tool to better understand and communicate what value the IT organization is set to deliver. However, to drive the creation of an effective IT Operating Model, we required additional, coordinated effort to combine the best aspects of various business and IT architecture disciplines, framework or standard and ensure we can be prescriptive in our undertakings. There is no single framework that is all-encompassing in its design and point of approach so as to be applicable to all business scenarios, and in the massive variety of toolboxes, relevance becomes of essence.
The architecture framework design must therefore begin with the customer (internal or external) request in mind, and limit the details strictly to a level that is sufficient to delivering the answers quickly back to the customer on that particular business use case. Losing the visibility to what originally was the business use case (and therefore why we, for example, modelled certain artefacts to a particular level or way) creates waste. Our efforts have shown that any framework with the primary objective of delivering business value should be an organic entity based on real-life products delivered with standard artefacts and entities in the meta model. Furthermore, such a framework should be context sensitive and at all levels aligned to specific business use cases.
Structured approach to building solution roadmaps and solutions
We created a structured approach to our transformation effort to help us comprehensively and holistically translate and structure business ambition to the nuts and bolts to ensure consistent and effective IT service delivery. We aim therefore to build up the complexity in our architecture framework through the services provided. We break down these services into deliverables and connect them into the architecture framework to ensure a consistent delivery and reusability of the information in further service delivery.
Step 3: Devise a Growth Strategy
Once you have established the IT Business Model, IT Operating Model, and related behaviour for the IT organisation, you should be looking for some growth of your IT Business. We must continue to be relevant to the business moving forwards and therefore our offering, competencies and job roles need to evolve over time in lock step with the business. Depending on how significant a gap there is between the IT Value Proposition and the Current Mode of Operations, an explicit growth strategy may be required to support organic growth, and in business terms, gain more market share.
IT has been traditionally viewed as a cost centre with fixed budgets provided on an annual basis. When value is not seen to be delivered, these budgets are reduced, forcing IT to deliver differently but at the risk of reducing further the value that they can realise for the business. What is required, say, to see the IT organisation recognized as a partner, not a service provider, and help it evolve to gain the trust of the business? What can we deliver for the same (or less) but that provides inherently more value if repeatedly adopted quickly by the organisation? What can we do to break out of our traditional domains, and seize the opportunities to take on a bigger role on the front lines of the business? I believe a growth strategy can be achieved through a number of different means.
We can improve organic growth by incorporating much of what we have seen to be successful in earlier undertakings such as delivering services based upon assured standards and frameworks such that repeatable delivery can be achieved. Delivering services outcomes which can be reused by more and more parts of the business reinforces the best practices we execute upon and reinforces the right operating model. This enhances how we are perceived by the business and therefore brings us closer together with each incremental delivery.
We can further enhance our perception with the business by identifying the appropriate business initiatives where we can pilot innovations, and ensure these can be delivered and thereby build trust with the key stakeholders. This is where we have found transformation programmes are an excellent way create and prove new operating models which continue to support the evolving business environment and requirements.
We can also work closer with Local / Business / Shadow IT teams and operate in such a way so as to be inherently advantageous to the business – after all, ultimately we all should have the aim of IT being the sole go-to organisation for the business to provide assured operational efficiency. We know we need to develop new competencies to achieve these outcomes and many times this is where you find those the easiest. Exposing services to these team gives visibility, opportunity to establish certain degree of governance and over time alignment with your central teams to a level it is easy to rationalize the team structures.
Anything which is delivered with these considerations in mind must be easily consumable by our customers so that they do not feel the need to go elsewhere.
@theopengroup #ogPARIS
http://www.opengroup.org www.opengroup.org/paris2016
Sven is a true professional in architecture, software development and service management. He has 18 years of experience across business process management, business architecture, enterprise and solution architecture, enterprise integrations and integration architecture, front-end application design, server-side enterprise application development and maintenance, and, due to his entrepreneurial background, everything between business administration, sales, outsourcing, and server and network management.
SKF is the leader in bearing business, offering not only the
bearing and related products but also rotating equipment performance
through industry and application knowledge on technologies around the rotating shaft.
You are almost there….
IT4IT is moving (badly) towards what Pragmatic EA have been advocating and advising clients for 6 years.
But there is a very important dimension you are missing.
Contact me and we can discuss.
kevin (at) PragmaticEC dot com
I like Sven’s willingness to challenge the IT4IT reference model. But I am not sure that he goes far enough. Yes an IT operating model should start with work on value propositions. But Sven suggests that there is only one value proposition, implying, like the reference model, only one value chain. My observation is that there are multiple and different value propositions – for providing an enterprise system, for providing desk top capability, for providing communications capability, for supporting digital business initiatives, etc. Each of these value propositions needs a value chain. Yes, some parts of these value chains can be combined, but there are parts that are better kept separate and there are other parts that should only be linked through common standards and processes or through data connections.
So, like Kevin, I think that Sven takes us part of the way.