Episode 5

Achieve Better Business and IT Alignment

Businesses are constantly under pressure to be more responsive, and Enterprise Architecture is one method driving change through better business and IT alignment. The ideas and principles from Agile Software Development enables more responsive organizational processes. In our blog post, “People do not update like Software” we mapped the principles from Agile Software Development to developing people. This time we will redefine Enterprise Architecture using the same approach.

Enterprise Architecture as a practice, has struggled to mature since its creation 30 years ago. Svyatoslav Kotusev, author of “The Practice of Enterprise Architecture: A modern approach to business and IT Alignment”, stated that, “the challenge with Enterprise Architecture is the distinct lack of empirical evidence of successful implementations using established frameworks.” Jason Bloomberg mentions in his article that, “unfortunately, Enterprise Architecture (EA) is often synonymous with the practice of documenting one person’s viewpoint of their company’s IT.” Despite Jason’s article being over 5 years old, we regularly see Enterprise Architects operating in isolation within their organization.

GiphyPiePlate

Enterprise Architecture is like pie plate spinning, with each plate representing the organization’s strategy, business processes, IT systems, and people. When managing these elements, we cannot take advantage of conservation of angular momentum, to set up steady states. In today’s business world, steady states are for dinosaurs. Political, economic, social, and technology landscapes are in constant flux; therefore, Architects must keep the plates spinning, yet actively work against the organizations acquired “angular momentum” to drive change. How can one keep the plates spinning, yet guide the organization through change?

Agile Enterprise Architecture

It takes a Village to Architect a Village

Organizations are dynamic multi-dimensional ecosystems. Where Enterprise Architecture fails is that a solution cannot be engineered through documentation. For an organization to be agile, it must work against its own momentum. The responsibilities of Enterprise Architecture should not be on the shoulders of a single individual, but shared by a multi-disciplinary leadership team. If Enterprise Architecture is separated into a specialized role, that separation creates a barrier to implementing change because the other stakeholders in the organization have outsourced their accountability to someone else. If we take a core element of Agile Software Development whereby the client is engaged throughout the development process, we require a governance structure that enforces regular engagement with the stakeholders in the organization. To satisfy this requirement, a team/committee made up of key executives, lead developers, and business managers should handle the organization’s IT. The shared accountability of the group will ensure that Enterprise Architecture practices have better business and IT alignment than an Architect working in isolation.

Differentiate Planning Methodologies

In Enterprise Architecture, current and future state assessments are a frequent practice. While the current state can be defined, the future state is unknowable. It is a good start to redefine current and future “states”, to current and future “focus”. Focus implies a goal or intent to work towards a particular state. While shifting from state to focus could be viewed as a play on semantics, the idea of focus shifts the perceived level of permanence when assigning goals. With new information it is easier to shift focus to a new objective than change the state of a system.

Using the diverse Enterprise Architecture leadership team, individuals within the group will have planning responsibilities that span from the long-term strategic vision to the day to day. Using focus defines the intended state at various levels of corporate planning. If we examine typical corporate planning methods, a common method is the development of strategic planning documents. These documents are invaluable in defining an organization’s vision, operating model, and required competencies. However, to justify the resource investment to develop robust strategic and operational documents, these plans typically cover timeframes between three to five years into the future. With the external environment changing so rapidly, core assumptions of a traditional strategic plan, risk invalidation shortly after implementation. Striking the balance between robust planning and agility is no easy task.

boardroom

In response, dashboard planning methodologies like the Business Model Canvas have become very popular. Canvas planning tools offer agility and powerful assumption testing frameworks to deal with uncertain future environmental states, the challenge is to organize what to do next? This is where the Agile method can help as it breaks down projects into small pieces that are completed in work sessions (sprints) that run from design to deployment.

Strategic planning by corporate leaders forms a long-term strategic vision (long-term focus), followed by the business model canvas to drive operational planning (medium-term focus) which defines short and medium-term projects through prioritizing assumption testing, and the Agile method managing project workflow (short-term focus).

Less Technology and More People

In our last blog, we made the case that the practice of software development has shifted from scratch, stand alone development to a highly automated process of linking application programming interfaces (APIs). Both the need for bottom up system design and the shelf life of a solution is on the decline. With off the shelf products covering more end to end solutions, the role of Enterprise Architecture is shifting from technical systems design to organizational engagement and change management. The best solution provides zero value if it fails to be embedded into the practices and habits of staff. People do not update like software and a team of diverse stakeholders responsible for Enterprise Architecture will have a vastly superior impact on initiating change than a technical genius working in isolation.

Make It Your Own

Despite the versatility and popularity of the Agile Methodology, it falls into the same trap as the frameworks for Enterprise Architecture because the practice of successfully implementing the ideas never fully represents a true implementation of the method. Organizations are multi-dimensional ecosystems of complex undefinable interactions that cannot be systematically engineered. Successful implementations reference the ideas and principles found in Agile and Enterprise Architecture and through iteration, discover what works for their unique set of environmental variables. At MERAK, over the last year we worked on developing an internal playbook to automate and streamline operational tasks. What we discovered is that the playbook was not a living document, but a state of mind embedded into the culture of our organization. This state of mind has driven an internal practice of collaboration that has organically discovered methods and practices we have used to better ourselves.