Key Business IT alignment criteria to strengthen your business strategy

In every organization, it’s crucial that their business goals follow the mission and vision of the company. The business strategy needs to be executed by running projects and activities to support this, otherwise, it’s like a dead letter. Companies that produce or consume software applications need to make sure their IT operations are aligned with their main business goals. This interplay is called “Business IT Alignment”. Implementing DevOps does not live in isolation. It is an important decision of the upper management that requires a thorough investment. Its ultimate goal is to deliver better software faster. Business IT Alignment can be seen as the same, but then on a more strategic level in the organization. Key Business IT alignment criteria to strengthen your business strategy.

Introduction

Many organizations face severe challenges in properly implementing true DevOps projects to support the greater initiatives. Not only from a technical point of view but also from a cultural one. Having to align Development teams as well as teams of System Operators already poses a big challenge. Yet it’s even more complicated to bring together the business representatives as well as the managers from the IT departments. It’s about this level at which the decisions are made and thus play an important role in the success of the DevOps projects.

A typical DevOps transformation leads to change everywhere in the organization. Nearly everyone and every process are affected. It’s not enough to “just do things a little different”. In order to manage these changes successfully, everyone should have a good understanding of where the organization stands right now. IT governance plays a crucial role in these changes and how well IT is tight to the business. For Dev(Sec)Ops and other initiatives, business leaders can utilize so-called Maturity Models. To define the current level of the Business IT Alignment, you can use a set of criteria that closely resembles the CMMI Maturity Model framework. This would lay out the foundation for the other aspects that drive organizational change.

5 Levels

Just like the CMMI model, there are 5 levels of maturity:

• Initial level: individuals are responsible for (small) successes. There are just a few IT governance-related processes and these are all defined as “ad hoc”.
• Repeatable level: previous success leads to the establishment of basic IT governance processes which can be repeated across the organization. However, these remain scattered.
• Defined level: every IT governance process is standardized, documented, and integrated into the management policies. They are all versioned and approved by the respective authorities and embodied in the governance framework.
• Managed level: decisions are made on an enterprise level and are based on every measurement of the components in the IT governance processes.
• Optimizing level: the processes generate valuable quantitative feedback to continuously improve them. Best practices and standards from the industry are adopted frequently.

In order to progress from one level to another, organizations need to have a realistic plan and solid roadmap to do so. The CMMI model of Luftman consists of six categories per level: communication, competence/value, governance, partnership, architecture, and skills. They all have an impact on the current and desired level of maturity.

Advance from level 1 to level 2

Suppose the upper management of the organization acknowledges their maturity level is 1 and they have the desire to advance from level 1 to level 2. This would result in a number of projects/activities for every category to make progress. The examples given below are just meant for inspiration to a fictional organization. Use them to try to change the culture of your organization so you can move forward.

Criteria 1: Communications

At level 1, your organization lacks a concrete understanding of Business IT-related processes and the interplay between them. If you want to progress to at least a limited Business IT understanding, you need to educate everyone in the organization that works in the software development chain from the strategic level down to the tactical level and further to the operational level.

In essence, you need a clear communication plan that emphasizes the connections and interdependence of these levels. You can show practical examples of use cases that won’t work (perhaps projects which were completely out of budget and delayed immensely). Your examples should be attributed to the misalignment of Business and IT. Every person on every level will ask him/herself the same question: what’s in it for me? So be sure to emphasize the advantages of the proposed changes.

In case you run a pilot project, be sure to “let the customer do the talking”. That means putting the responsible team at the forefront and letting them show the results to whoever it may concern. Not only the (upper) management but also everyone who works in the (IT operations). Using this approach they see the clear benefits.

Actively correct people that still talk about “us and them” if they refer to Business or IT-related departments respectively. There should be no silos, it’s a single organization sharing the same goals and mission.

When it comes to important decisions to be made, be sure to always invite a business representative as well as a technical manager. Don’t operate in isolation, even if it may sound like too much overhead.

Criteria 2: Competence/value

The competence/value category gives an insight into how well the organization scores in terms of actually carrying out its core duties. You need to measure how well you perform before you jump from one level to another. In the case of companies just measuring some technical aspects rather than focusing on cost efficiency, they don’t have a clear view of what their products/services would cost compared to what their revenue is. Essentially they don’t know how they perform and if they can expect a positive result at the end of the year.

In the case of this scenario, you need to explain and show why technical measurements are needed but do not add so much value to the business. For example, measuring up-time has no effect if scheduled downtime happens on the weekend when no one uses the system.

Off course that would hurt the people that actually implemented those measurements, therefore it’s crucial to explain how Business processes are related to IT and the added value of IT. Measurements which are focused on functional cost efficiencies such as the number of returned products or customer service tickets to deal with complaints are much more useful.

Once you translate that back to practical advantages to the responsible departments. Some examples could be: an increased budget to extend the team, an extra budget for training and certification, or even a salary rise.

Criteria 3: Governance

Organizations that do not have established (the most relevant) governance processes are characteristic of reactive responses to challenges. Priorities change constantly and no one knows how important decisions are made. Governance is merely a “cost-center” that does not have a positive impact on the revenue streams. If this is the case, companies need to mature to clear processes on a tactical functional level as a start.

First of all, everyone needs to stop perceiving governance as a cost center. There should be teams to explain why proper governance is important and how proper processes contribute to faster software delivery with more confidence in the developers. Practical examples that adopt “best of breed” methodologies can be translated back to the global organization to act as guidelines that apply throughout the organization.

Processes need to be written down, and easy to understand and Product Owners should be trained to incorporate their impact of them on their backlog. With this is mind, developers also gain a greater understanding since things become practical. This helps to gain more support.

Criteria 4: Partnership

Business and IT departments should work in tandem to achieve business goals. There is no room for conflict since there is a lot to improve. From the Business perspective, IT is only seen as a cost center that wastes money. On the other way around, IT departments see “the business” as a roadblock to their projects and activities. This viewpoint needs to change.

To solve this kind of conflict, try to establish a culture in which both parties work on the same goals and not just protect their silos. Once IT is an enabler there is room for more. IT should also come with its own initiatives. Convince the management that there should be room to execute that kind of activity as long as they support the main business goals.

Plan sessions to seek a common understanding of what people do, even though not everyone will understand all of the (technical) details. For example: let a pipeline developer show how to solve a bug and let the new version of the application go all the way from source code to production. Business people see what is needed to achieve even a simple change. On the other hand, let a controller show a business case in which the costs and revenue are split. Even if this might be just a “boring document”, people see each other’s work.

Criteria 5: Architecture

Consider architecture as the business architecture that provides an overview of how the organization functions and how departments and processes are related together. Level 1 is focused on “traditional activities” such as accounting, email, and customer service. In level 2 there is a focus on (business) transactions that actually generate revenue. The crux is to shift the mindsets of decision makers to push only the initiatives that fall into this category.

Therefore it’s good to always ask for justification for any initiative. For example by asking questions like:

• In which way does the initiative have a positive impact on our (core) services?
• How much money/returned products/complaints do we reduce when we execute project XYZ?
• What is the improved quality when we carry out this initiative?
• What are the long-term effects, both positive and negative in case we go along with these activities?
• Do these things support our core business or supporting business?

These kinds of questions make people think about what they are doing and why. Based on this, business architects can establish a common architecture to include all aspects. Technical architects take these as a reference to build their technical architectures. Together this forms the bridge between the business goals and the actual practical implementations of the perceived projects.

Criteria 6: Skills

If an organization wants to graduate from level 2 to level 2, people need to have the right skills. With proper skills everywhere in the organization, especially in the IT departments, the risks to carry out business are too high.

Consider building a new application that will be the first one to land in the cloud. If IT personnel does not have enough skills in terms of security, the company risks data theft and security breaches. This is a threat to the entire organization. There is little reward for both parties (Business and IT operations) when things go wrong and this leads to ad-hoc decisions such as extra technical training. Skills need to differ across the organization so everyone gains a certain specialty. Together they are united.

To overcome the skills challenge, it’s vital to create an education plan and define required and “nice to have” skills for each and every role. Don’t be confused with group skills on function (level) since people can have multiple roles instead of a single function in the organization. It’s crucial to adjust the skills according to the maturity of the Business IT interplay and also be sure to not only provide technical training to IT personnel. They should also understand the basics of what personnel of other departments is doing. Internal workshops of 1 hour might be sufficient to get a better understanding. This brings both worlds closer together to focus on the most relevant goals.

Conclusion

In this article, we’ve summarized a bunch of valuable criteria to assess the current level of your Business IT Alignment as well as tips and tricks to advance from one level to another. These can be very well applied in organizations that transform themselves from Waterfall/Agile to DevOps. Use the information which has been presented to change the culture and processes of your organization so valuable projects and initiatives do not fade away unnoticed.

If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.