IT Frameworks: Will they marry?

From what I read and experience, I think many organizations are struggling to pursue an agile transition while keeping the lights on of services and application they already provide. They are usually overwhelmed by a myriad of additional roles, practices and structural elements and cannot imagine how to blend all this together.

In this article, I’ll extend my own reasoning on the issue in order to spark a constructive discussion and come closer to a pragmatic approach.

All current IT frameworks share a common goal: Deliver (and operate) working software which satisfies the customer/ end-user.

Every framework pursues this goal with a different focus and other basic assumptions resulting in different routes to IT’s holy grail. The frameworks I got to know so far are reasonable samples of good practices but they are also inherently limited by their specific focus (stability, speed, reliability) and consequently none is complete.

As there is only one system/ service/ application, organizations face the challenge to adopt and adapt elements of different frameworks to support their full IT-business scope and need to make them work together “somehow”.

But “working together somehow” is in today’s competitive environment a completely insufficient objective: We must expect nothing less than a synergy between the selected framework elements in order to really create and operate better software.

In consequence do specific roles and processes of these frameworks cater for specific aspects of the software’s creation process and its productive life. This creates several structural challenges:

a.)    Practices which are well suited for one context can be dysfunctional in another 

b.)   Roles & processes from different IT frameworks collide during execution

c.)    Management levels of these roles are not congruent and create contradictions

This situation must be improved so that value-adding practices are executed, roles and processes are reasonably aligned and a functional life cycle management can be established and maintained.

One of the lessons I learned during my years in IT is, that the structure of existing software is stronger than any organizational design [1]. Therefore, the clarification of the team structure along the borders of the software applications following the architectural precepts of high cohesion and loose coupling is the initial step in this process. This will result in reduced horizontal coordination needs between teams and thus lead to higher autonomy.

After having aligned team and software structures, processes and roles must be defined and reconciled.

As for the working  processes: Select the best suited practice set for the job at hand. Go for ITIL when the team has primarily operational responsibilities but select CMMI for Development or the engineering practices of  the agile toolboxes if development is focus. Those decisions often take place in a larger organizational context under the banner of standardization and there are no easy answers. Just consider the following points:

• Leverage the level of autonomy the software architecture landscape grants a team – it’s a gift! If the team can operate predominantly autonomously, there must be really compelling reasons to favor alternative practices over the ones best suited for the job at hand.
• Rigid implementations according to the book are often a recipe for failure. IT frameworks are practice-based and allow or even encourage process tailoring, which can work wonders.
• Standardization is never an objective in itself. The overall benefit of standardization must be balanced against local performance losses. Scrutinize cost, risks and benefits thoroughly. 

Finally, management roles and processes: The reconciliation of management roles and processes are the last step on the top layer. It is an obvious organizational imperative to streamline managerial roles and processes in order to ensure informed, effective and efficient decision taking with minimal synchronization effort. The key differentiator to consider is the management level of those roles (operational, tactical, strategical).

Leading roles for the same scope and the same management level are good candidates to become merged into one function. For example, the same person could act as (ITIL-) Service Delivery Manager as well as (SAFe-) Product Owner for the respective service or application. A quarterly service review could be well aligned with the planning of the next product increment to ensure that problems become addressed in the form of enablers which are fed into the product increment planning.

IT business is more complex than any IT framework could ever envision which forces us to find pragmatic solutions for real-world problems. Do resist the silver bullet syndrome (rigid implementation) and face reality in its full complexity.

This brings me back to the initial question: Will IT frameworks marry? From the standpoint of an IT organization it seems a necessity. But unless it is a love match between them, software leaders are well advised to define the needed synergies across frameworks as central outcome of their respective initiatives.

[1] This symptom reflects the reverse function of Conway’s law (see also Wikipedia)