Factoring in Complexity in IT Performance

Complex Systems Development (large IT departments) is by definition complex. But it is vitally important for us to reduce this complexity in the areas where performance is most affected. In this post we look at how Culture, Methodology, Legacy Burden and Enterprise Architecture will affect the performance of the department.

Allow me to start with a fable

It might be a bit of a reach but think of the story of the Tower of Babel, an origin myth from the Book of Genesis. It could prove to be an interesting anchor-tale when we discuss complexity. The people set themselves an ambitious goal of building a tower to heaven, and God himself thought they might succeed, which is why I think their plan is worth analyzing. Spoiler alert: God destroyed the project by confusing them with different languages — messing up their culture.

Now, why would a modern IT leader look for inspiration in a Bible story from thousands of years ago? My claim is that if a tale has survived for so long, there might be elements worth looking at. And their ambitious project surely resembles some of the IT projects I have witnessed.

TThe specific points that I refer to as Complexity, are part of the “C” in the Nucleon formula. They differ from the areas discussed in the on Organization (and from the “O” in the Nucleon formula) in a number of ways, including the fact that they are much harder and take significant time to change.

I’ve found four relevant cornerstones to the Babel story that correspond well with my own findings in complex systems development of companies today:

Language

Whether you call it language or culture, it is the obvious core element of the story. The whole world “had one language and a common speech” is how the story begins, and it was this element that God destroyed, confusing them with many languages. So much for the tower: they had to cancel the project and comply with God’s original intent of scattering them all over the world. But the common language was their overarching strength.

Architecture

The second core element mentioned in scripture was a blueprint, which is similar to enterprise architecture. “Come, let us build ourselves a city, with a tower that reaches to the heavens” refers to a master plan that would have helped them to organize all their work wisely.

Methodology

The third element was the reinvention of their methods for construction materials. “They said to each other, ‘Come, let’s make bricks and bake them thoroughly.’ They used brick instead of stone, and bitumen for mortar.” In biblical times, people built larger constructs out of normal stone and mortar. Not having enough stone in that specific geography forced them to change their way of producing materials (methodology) to adapt to the new circumstances. They burnt hard bricks and used tar as mortar in a whole new way (waterfall to agile?)

Legacy

The fourth element is implicit in the story and requires a closer look. The legacy of the people who gathered in Babylon was a firm commandment from God to spread out all over the earth. By ignoring God’s commandment in favor of their own ambition “so that we may make a name for ourselves and not be scattered over the face of the whole earth,” they released an enormous amount of energy (to no good end, but that is a different matter). They no longer had an anchor of history to drag their performance down.

IIT is unique in that it has so many different layers of complexity. Areas include security, cybercrime, big data strategies, fraud detection, hardware and software contract negotiations, operational stability, backup/restore strategies, CMMI work in general, education and training needs in the organization, external and internal branding/marketing and technical communication/network strategies.

All are vital to the survival of your business, and there’s no doubt that ignoring them can result in your organization landing on the front page because of a security breach or an operational glitch. Despite their importance, they are not severely impacting your performance in the area of application development, and that’s the area that time after time has proven to be the most important to efficiently and productively is a differentiator for your business.

Top management can add value by providing the money, mental support and human capacity needed to all important areas like security but should not be distracted from their focus on improving the application development area.

There are four IT-related complexity areas that I believe need top management’s specific attention in every organization:

• Culture
• Methodology
• Legacy
• Architecture

Culture

Culture, while often seemingly intangible, is an enormously important area for anyone striving to optimize development team performance. There are six basic reasons why people work, and they aren’t created equal. Play, purpose, and potential strengthen adaptive performance while emotional pressure, economic pressure and inertia weaken it.

Having a solid and positive culture means everything to any working team, as well as to an IT development department. It makes an enormous difference.

Sometimes big companies lose their appreciation or sense of urgency about maintaining a positive culture, but the simple truth is that if you have an unhealthy culture you will fail. You need the best IT people you can find, but those good people can’t survive or thrive in a bad culture.

In Nucleon, I look at six empirically proven cultural performance indicators:

Play – the feeling of having fun doing your job
Purpose – when your work contributes towards something meaningful to you
Potential – when the job is an active asset towards achieving your goals
Emotional Pressure – when emotions are forcing you to work
Economic Pressure – when you work solely for financial reasons
Inertia – when there is no good reason why you work at all

These six drivers describe not only core motivational factors but also the underlying performance cycle. Altogether these cultural assets have been shown to account for 17% of performance.

Development Methodology

In our research, we have found that there are three main performance effects of different methodological approaches; agility, practical experience, and team consistency. Not being agile and not having the practical experience within the team can reduce your team performance by upwards of 51%.

The methodology is a rigid area of competence, and that’s probably because IT development is so difficult. It is tough for IT people to work with business people who constantly change their minds about what they want, and it is equally difficult to design and develop a perfect application that is easy to maintain in the operational environment.

In the end, the IT organization is always the target of critique when the systems don’t reflect the solution that the business had in mind. As a result, IT people are very conservative as to what the best development approach may be.

In general, the choice of methodology should be the same throughout your organization, but the most important thing is to have the same knowledge and choice of methodology within an individual team — teams must be harmonious. That being said, today’s talent has been brought up with agile development methodologies, and even if it is not optimal for productivity purposes, you want to be flexible enough to be able to move your developers from one project to another. You can accomplish this more easily if your entire organization is working with the same modern methodology.

The Nucleon formula helps you measure the implementation of your methodology and what it’s doing for your performance. It does this by assessing every individual’s maturity in the new methods and then collectively looking at the compatibility of the complete team.

Legacy

A lot of legacy applications can significantly hamper development performance. In certain IT environments, we have seen a performance drag of up to 18%. We measure the legacy score as the share of systems the individual is working with and interfacing to that are not state-of-the-art systems with strategic value for the IT infrastructure and future development of the business.

Generally speaking, existing systems are not altogether terrible. Businesses live and thrive using these systems, but they may be taking up far more resources than you realize.

Companies might have to live with bad decisions for many years and end up with much higher maintenance costs than originally anticipated. Some organizations allocate more than 80% of their staff in maintaining old systems and the implementation of new legislative requirements within those same systems.

As a manager, you need to know what resources are allocated to the maintenance of obsolete systems versus your core current systems. Knowing this gives you an overview of what resources are available for the implementation of new, more efficient systems.

Another major aspect of old legacy systems (other than the maintenance burden) is that they are difficult and expensive to integrate into new (build or buy) systems. If your business functionality or data are not easy to access, it will drag performance out of an otherwise straightforward integration project.

Nucleon measures the legacy impact by asking individuals to evaluate how large a share of their current environment (interfaces, platforms, systems, etc.) is coherent with the above definition. This is due to the fact that the legacy impact can be very different in different parts of the organization, and to differences in factual and perceived legacy burden. An individual might perceive a larger burden than there actually is, but their perspective is still relevant, as it’s the way they will experience it.

Most often the wisdom of the crowd will be a better estimate than a single individual from the Enterprise Architecture department deciding on a legacy level. Therefore, it is important to involve the entire development organization and not just someone with more stars on his shoulder.

This legacy number tells you exactly how much development capacity you really have available to serve your strategic new development; it’s likely to be less than you think.

Architecture

The architecture score of a team is a product of the quality of their APIs, the degree to which the architecture allows for reuse, and how well the teams are future-proofing their applications in development. The sample space of the architecture score falls between 0.74 and 1.

AArchitecture is the art and science of giving shape and form to buildings, spaces or physical structures. In IT, the architecture department supervises the overall picture or the master plan. It governs the technology stacks and is responsible for durability, maintainability, and interoperability. It should be an authoritative guide to development teams and business people.

Architecture is the most basic and important function of all the support staff areas in IT: if the architecture department doesn’t work well, all projects will suffer.

Companies with service-oriented architectures are much better positioned than those who have not prioritized this function. An obvious example of architecture’s benefits is seen in how much you can buy from cloud services; what was impossible to envision only five years ago is now easy to see as a practical and viable solution.

The chief ambition of the architecture function is to leave the IT department better than they found it. Architecture should be easy for developers to navigate, and so too should choosing approved technology stacks for projects. Requirements for interfaces should be simple to understand and the environment should encourage reuse of existing stubs and code. It should also discourage the development of proprietary interfaces. Strong enterprise architecture will help you avoid redundancy and improve the quality, availability, and sharing of data. It will save significant expense.

Architecture can be measured in many ways. While many process-oriented measures of architecture seem to be great measures of effectivity, the view of architecture is often isolated to structure and management and doesn’t take into account some of the more operational benefits.

Our measurement of architecture is based on the degree to which reuse is enabled, used and secured. This is done by looking at the level of state-of-the-art APIs, the ability to use code from other projects or repositories and enabling the future use of the current project.

This performance view does not isolate architecture to a measure of documentation or process rigidity but instead looks at how well the architecture is enabling fast production and ensuring that all development carried out will have an accelerating effect on future work.

Complexity is the enemy of performance. If you use the Nucleon formula and find that you’ve scored well, you are well-positioned to enable your high-performance teams to function optimally.

I encourage you to read chapter 5 of my book, Nucleon, for much more details and insights on IT complexity