Do you begin an enterprise transformation with the business or with IT?

For many companies change is a way of life. In fact, companies need to change in order to survive. Enterprise transformation deals with the fundamental organizational change that impacts how its core business is conducted. This need for transformation change can be caused by internal or external factors, but the result is a shift in how the organization relates to its wider economic environment.

Enterprise transformation can be defined as the fundamental change to the way an organization operates, whether that be moving into a new market or operating in a new way. It is an approach that attempts to align an organization's activities relating to people, process and technology more closely with its business strategy and vision. This fundamental change aims to meet long-term objectives.

For the past year or so I've been delivering TOGAF certification workshops. TOGAF stands for "The Open Group Architecture Framework" and it is the de facto standard for enterprise architecture. Enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. According to the Open Group consortium (https://www.opengroup.org/), the TOGAF framework enables organizations to effectively address critical business needs by making sure everyone involves with transformation speaks the same language, by utilizing resources more effectively, and by achieving a demonstrable return on investment.

TOGAF is a huge framework and I don't wish to get into too much detail here. Just not enough time! TOGAF is not the only framework to implement architecture changes. But from my experience it works quite well and I want to share some of the basic complements of TOGAF that might assist you in our enterprise transformation journey.

A question was asked about how to begin the process of enterprise transformation. "Do we start with the business first and then address technology or the other way around?" Interesting question. In my opinion business and IT are two sides of the same coin. You should not transform one without considering the impact on the other.

To keep it simple, I want to discuss the Architecture Development Method (ADM). ADM is a major component of TOGAF. There are 10 ADM phases. Phase B is related to the Business Architecture, Phase C is the Information Systems Architecture (which includes Data and Applications), and Phase D is the Technology Architecture. For the purposes of this article I will only be discussing these 3 phases.

The ADM is iterative, over the whole process, between phases, and within phases. For each iteration of the ADM, a fresh decision must be taken as to the breadth of coverage of the enterprise to be defined, and the level of detail to be defined. In TOGAF we start with Phase B -- the business phase. This is where we document the current baseline of the business architecture and develop the future business architecture state. It is possible to not have the completed target business architecture defined before moving to Phase C or Phase D. Because the ADM is iterative, you can jump to another phase, do some work, and then jump back to work on a previous phase. While it would be ideal to have a completed target business architecture sometimes you have just enough defined to understand the transformation path. While this path is being further defined, you can work on the information system and/or the technology architecture phases.

TOGAF includes the concept of "target first" and "baseline first." This can help us in our decision on where to start. If we know how we want the future state to look like, we could begin with the target first and work our way back to the baseline. If we are not sure what we want the future state to look like, we could begin with the baseline and work our way to the target state. Regardless of which path you choose, in the end, you need to have both the baseline and target well-defined. What we are looking for is the gap between what we have and what we need. And it is within that gap that the enterprise transformation is defined and takes place. The baseline provides us with information on our current state. The target provides us with information on what we would like to achieve at the end of the transformation. With this information, we can put together a transformation roadmap and the ability to measure our progress/success in achieving the target state.

While working on this transformation we can also apply other frameworks/methodologies to create a more effective and efficient future state. Some of the names you hear these days are Agile, Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and DevOps to name a few. I will cover these topics in upcoming articles so stay tuned.

In the meantime I'd love to hear your thoughts. What enterprise transformation challenges have you faced? What frameworks if any do you use? What would you do differently the next time?

Original article was published in cio.com. See article here.