Continuous architecture combats dictatorial EA practices
To thrive today, Agile businesses must outgrow the architecture review board and enterprise silos to create an integrated culture of continuous planning and management.
Enterprise architects that stick to rigid developer and software management frameworks may struggle to make the most of the innovation and churn of Agile practices. Instead, experts in these organizations should incorporate input from the bottom up -- meaning users and developers -- rather than imposing rules from the top down.
This approach creates a continuous architecture, a structure that draws ideas from multiple sources -- not just from a strict plan -- and brings needed flexibility to the review board process. With a steady stream of evaluation and communication, an organization should be able to create products that are not just better, but that more closely align with actual business goals.
The downside of command and control
Stand-alone enterprise architecture teams facilitate a command-and-control relationship with developers and IT operations, and an architecture review board must process all the deviations. This type of hard-line approach is necessary, particularly when there are dysfunctional, wasteful and duplicated IT systems and processes in place.
However, experts are beginning to see governance being distributed from strategy into operations with Agile approaches that use continuous architecture and continuous planning practices.
With an Agile enterprise architecture, when teams embed requirements and governance rules in the work or the project initiation, it's up to the project manager or the Scrum master to get the right resources in place to stay compliant, said Gordon Barnett, an analyst at Forrester. Companies require structured communication, thorough documentation and clear policies to safely move architectural accountability out of a dedicated team.
Enterprise architects must articulate the relationship between business capabilities and the components furnished at the services and product level, said Todd Tucker, VP of standards, research and education at the TBM Council, a nonprofit organization devoted to instilling business practices in IT.
Build an enterprise architecture service catalog
Adaptive IT organizations excel when they create an enterprise architecture service catalog, which isn't difficult to do, Barnett said. He outlined the steps that go into making one:
First, understand what challenges stakeholders have.
Decide what services you can deliver to help them.
Create a roadmap for when you can deliver services, which will lead to your strategy.
As you make changes, develop a backlog as you would for a product.
Finally, constantly check whether those services are right for the target consumer.
Lufthansa Systems' Lewe said organizations should standardize their product development, management and support workflows as much as possible from the start.
"We were too willing to support any custom configurations in Jira from the beginning," Lewe said, citing the burden now of maintaining individual workflows for well over 15,000 users.
Invest the time to create strict policies and define standard processes so that the enterprise architecture is clear and consistent.
"We have written policies over time, and it's constantly growing," Lewe said. "Now we have a very good service description, but we should have done it earlier."
Continuous architecture and planning
To encourage an Agile enterprise architecture, software teams must devise a method to get bottom-up input and enforce consistency.
Apply tenets of continuous integration and continuous delivery all the way to planning and architecture. With a dynamic roadmap, an organization can change its planning from an annual endeavor to a practically nonstop effort.
Lufthansa Systems, a software and IT service provider for the airline industry under parent company Lufthansa, devised a layered approach to push customer demand into product architecture planning. Now, the company can continuously update and improve products, said George Lewe, who manages the company's roster of Atlassian tools that underpin the multi-team collaboration.
"We get much more input from the customers -- really cool ideas," Lewe said. "Some requests might not fit into our product strategy or, for technical reasons, it's not possible, but we can look at all of them."
Lufthansa Systems moved its support agents, product managers and software developers onto Atlassian Jira, a project tracking tool, with a tiered concept. Lufthansa Systems individualizes products for each customer, so one product that 20 airlines use is made up of 20 discrete projects in Jira, each staffed with support agents.
This is Level A -- what Lewe calls their face to the customer. At Level B, which is service support, all the requests and tickets from Level A get duplicated and linked to one overarching product. A service support manager and product manager review the information and coordinate to plan improvements. The product manager supplies a roadmap to Level C, which is the software development team. Because everyone works in Jira, it's an effective way to organize across departments, Lewe said.
"This setup highlights the importance of the service owner or Agile product manager -- they're responsible for the business value of their service or product," TBM Council's Tucker said.
Because product managers have that responsibility, they should have a hand in defining its capabilities. They should also collaborate frequently with enterprise architects who can ensure the product innovation fits into the overall architecture and that individual efforts aren't duplicated. Ongoing feedback is key to forming a continuous architecture.
The TBM taxonomy provides a standard set of categories for costs and other metrics.
Mapping components to outcomes
Tucker recommends organizations integrate what's called the TBM taxonomy with their existing frameworks so IT can connect the dots from product- and service-level technological components to business outcomes (see the figure). The taxonomy provides data on what's consumed and where there are gaps in the software, as well as the data and infrastructure admins need to support a digital capability, he said. This way, Agile teams can move autonomously, but all in the right direction.
Forrester's Barnett agreed that organizations must understand what areas change frequently, and they must also collect data to gain insight into how you use the architecture.
"Move the resources and assets of your organization to the point of need at the time of need," he said.
Effective continuous planning is based on assessments of both external and internal environments, Tucker said. The Agile continuous planning model still requires careful thought.
"You're reacting to things being delivered in shorter time," he said. "Rely on data to understand where you actually are in terms of delivery, performance, feedback [and] risk."
At Lufthansa Systems, the interrelated teams keep documentation consistent via Confluence, a sister product to Jira that manages collaboration in real time. The teams share and update meeting minutes, user manuals and other product support information with the tool.
Barnett also noted that continuous planners can provide design patterns, standards and principles that act as guardrails to prevent the introduction of too many ideas at once.
Control without power grabs
For organizations that want adaptability without a full continuous architecture and planning overhaul, there are simple ways to ensure the enterprise architecture is relevant and valuable.
First, make it align with the business's needs, not the other way around. Architecture purists who focus only on strategy solve a problem that no one has, Barnett said.
Also, an enterprise architecture team can't be the department of no. If developers, technology platform managers and other team members face too much resistance, they'll bypass the architecture review board, he said. Rather, architects should act as an advisory panel that shows developers options for the best path forward, explains why it works, and expresses the feasibility and consequences of alternative approaches.
When EA gets their fingers in there and tries to dictate, you get friction between the groups.
Gordon BarnettAnalyst, Forrester
Tucker suggests that enterprise architects follow the money, so to speak. Their company's financial management system already tracks every AWS deployment, each contract for outsourced web development and other spending. Use that kind of tracking system to gain visibility into the deployed architecture and see how that cost structure compares to the products, services and architectural patterns your teams have agreed to implement.
Finally, architects should oversee everything, but they should also grant a certain amount of latitude to operations and development teams. These people need to keep workloads live and release new features.
"When EA gets their fingers in there and tries to dictate, you get friction between the groups," Barnett said. The developers have to deliver a product, and IT operations has to support it. Get their representatives into the same room as architects to examine problems and strategy.
