“We have a mess on our hands,” said John, the CIO of an international hospitality and resort enterprise I’ll call Horizon (I’ve fictionalized the story but it’s based on a combination of true stories). “Every line of business wants something different from IT. There’s lodging, resort operations, restaurant operations, facilities management – even housekeeping, and they all want their own apps.”
It’s a familiar story, of course. I needed to get to the crux of the matter. “Of all the challenges you face, what’s the biggest?” I asked. “What keeps you up at night?”
“Lack of respect,” John replied. “IT has spent so much time and money over the years before I took this role, just trying to connect everything together and keeping the lights on, that we don’t have any time or money left over to innovate,” he explained. “So now the lines of business feel they have to go around IT and buy apps on their own.”
“Which only makes the problem worse,” I added.
“Precisely.” John ran his fingers through what was left of his hair. “I need to get Horizon out of this Catch-22, where IT’s internal issues prevent us from supporting the business, so the business makes their own technology decisions, which only make our integration, portfolio management, and governance issues worse.”
Time to apply my new approach, the Bloomberg Agile Architecture Technique. The Bloomberg Agile Architecture™ (BAA) Technique offers a way of thinking about and doing architecture that is laser-focused on business agility as the fundamental business driver. Yet while the BAA Technique is an approach to Enterprise Architecture, it’s not a framework or a methodology. In fact, if you’re using TOGAF or SAFe or Zachman or any number of other architectural frameworks or methodologies, the BAA Technique doesn’t require you to throw them out. Rather, the BAA Technique simplifies your choices, as it lays out a particular path through all the options facing the architect that leads to greater business agility. Here’s how it works.
Applying the Bloomberg Agile Architecture Technique within Horizon
The starting point for Horizon’s BAA effort is to cast their problems as business agility drivers. Business agility breaks down into three core priorities: responsiveness and resilience, which are the tactical, reactive drivers, and the strategic, proactive driver of innovativeness. Responsiveness means being able to respond quickly and efficiently to positive change in the business environment, while resilience suggests being able to bounce back from adverse change. Innovativeness, in contrast, means being able to introduce change into the business environment intentionally, in order to achieve strategic benefits like increased market share or penetration of new markets.
At its core, however, BAA is a technology-driven technique, as it provides specific approaches for leveraging modern technologies like Cloud Computing and Big Data Analytics to achieve the business agility goals of the organization. The goal of the architecture exercise, therefore, is to connect the dots between the enterprise agility drivers and the necessary technology changes the IT organization must make in order to achieve those goals.
It’s important to remember, however, that BAA is itself an Agile technique – that is, instead of a heavyweight, big-bang approach, BAA favors an iterative, problem-focused approach that seeks to achieve real progress in a practical, step-by-step manner. As a result, even the most intractable of legacy rats’ nests can benefit from the BAA Technique.
Conversations with Horizon’s line-of-business executives uncovered their agility drivers. They wanted to expand into new markets, improve customer satisfaction in order to increase their repeat customer rate, and add new resort offerings to better compete in existing markets. We worked through these drivers, identifying the core challenges that centered on dealing with change. Numerous challenges presented themselves, and we worked them into their BAA Roadmap (more about such roadmaps in a future Cortex newsletter).
After a few weeks helping them understand their as-is architecture as well as their BAA Roadmap, we settled on a pilot project to serve as the first iteration of their overall BAA deployment. Such pilots serve several purposes: they solve a real, albeit limited problem; they prove the technique works; they get the team up to speed; and they establish an iterative pattern by serving as the first iteration. In the case of Horizon, the pilot focused on their loyalty system.
The loyalty system is supposed to track repeat customers, in order to recognize them as Horizon’s best clientele by offering special promotions, personalized service, and other premiums. Horizon’s problem wasn’t that they didn’t have such a system; their problem was that they had too many loyalty systems. The company had grown internationally through various acquisitions over the years, which led to the addition of various loyalty technologies. On top of these corporate acquisitions, various line-of-business managers within regions had taken it upon themselves to purchase their own loyalty apps. The result was a complicated mess that often didn’t recognize a loyal customer from one geography to the next, as well as causing a variety of related problems, like inconsistent and redundant emails to customers and front desk staff who didn’t know whether someone walking up was a regular or not.
A traditional architectural solution would focus on hammering out the to-be architecture, which in this case might center on a single loyalty system that replaced the motley assortment they started with (which would be unlikely, as every line-of-business manager favors the one they’re using), or more likely an approach to integrating existing systems so that they would present to the customer as a single, coherent application. Such an effort would likely bog down when the data architects tried to rationalize the various and sundry data models that each individual loyalty app depended on. Many months and perhaps millions of dollars later, Horizon might have ended up with a working loyalty system.
That is, until the business environment changed. Perhaps due to a new acquisition. Or maybe an addition of a line of business (there was some buzz about acquiring a cruise line). Or even regulatory change. Now that tightly integrated but fragile loyalty system would no longer meet the requirements, and it would be back to square one.
With BAA, in contrast, there is no to-be architecture – or at least, not in the physical sense of architecting a working app as above. Instead, the focus of the architecture is expecting and supporting ongoing change by specifying technology that is inherently flexible. In other words, architects must begin at the Meta layer, the top layer of the BAA Abstraction Layers diagram below.
I discussed the Meta layer in my book, The Agile Architecture Revolution, as well as in other articles over the last few years. At the Meta layer, architects (and others) treat business agility as a metarequirement (a requirement that affects other requirements). The also hammer out metaprocesses (processes for creating and modifying processes) and metapolicies (policies for how to do governance). In the case of Horizon’s loyalty system, work at the Meta level focused on how they will deal with changes that might impact the loyalty system, and what processes and policies at Horizon should be put in place to deal with such change.
While architects must generally start at the Meta level, in practice each iteration should be tackled both top-down and bottom-up at the same time. The architects must have a good understanding of existing technology (working at the Physical layer) as well as the core abstractions that are in place for dealing with that technology (for example, data schemas, Web Service or other API specifications, etc.), which take place at the Abstracted layer. As the team works through the iteration, they will eventually derive recommendations for how to make changes at the Physical and Abstracted layers, but in order to make such recommendations, the architects’ focus must shift to the Dynamic layer.
The Dynamic layer is the key to the entire BAA technique – the glue that ties organizational and process efforts at achieving agility at the Meta layer to the changes Horizon must make to their application and infrastructure environment to support the agility drivers that apply to this iteration. As I explained in the last Cortex newsletter, the focus of the Dynamic layer is on creating abstract models that the underlying infrastructure can resolve at run time into the specific logical representations in the Abstracted layer. Get this step right and you’re on your way to implementing technology that is inherently flexible.
The Intellyx Take
The work so far at Horizon has really just begun, of course. Understanding that abstract models must drive the underlying technology decisions is an important first step, but we must still answer the how question – how to get technology implementations that follow the BAA technique to actually work. I’ll be filling in such important details in my Cortex newsletter as well as my DevX Agile Architecture Revolution blog over time. (If you can’t wait, then join me in one of my upcoming Bloomberg Agile Architecture Certification courses or drop me a line.)
In the meantime, take another look at the BAA Abstraction Layers diagram above – especially if you’re an architect with years of experience dealing with other, similar layer cake diagrams. True, the bottom two layers are tried and true – nothing particularly new there. To really understand why BAA is different, you must understand the top two layers: in and of themselves, and how they relate to everything else. Simply adding one layer of abstraction on top of another is also a familiar architectural rat hole, but one I’ve been careful to avoid. If you understand why that is, you’re on your way to understanding Bloomberg Agile Architecture – just as John at Horizon is well on his way to getting some respect.
Horizon is a fictitious company. Any similarity to a real company is purely coincidental. Image credit: Kevin Dooley
