Here at Bottle Rocket we often service some of the largest and most engaging brands. In the past few years alone, we have worked with (and launched) digital experiences and FinTech, (Quick Serve) Restaurants, Hospitality, Oil & Gas, Automotive, and even Retail.
And while each of these brand offerings has been highly unique and specific to their brand promise, we have noticed some of the same early questions being asked. Driving towards business strategy is paramount so we facilitate this conversation. Aligning around the right product serves as a cornerstone for what is to be built. Intuitive design and information architecture are certainly pillars of the Bottle Rocket promise. But the Technology to advance those experiences has been our mark of excellence.
Through these findings, we have designed an accelerated information gathering framework that grounds each subsequent conversation around technology. This solution architecture thinking has helped make good on brand promises and has been a potent differentiator of ours.
It's easy to get lost in the sea of ecosystem entities, technology stack volatility and (our favorite across many industries) security & compliance.
In the engagements of yesteryear, we found ourselves arranging countless conversations to gather the information needed to take action on our deliverables. And while all conversations with the client are valuable they became impractical. Meandering through so many business groups and piecing together architecture became a primary resource consumer. So we invented the Solution Architecture Quadrant.
The Solution Architecture Quadrant is a diagram exercise whose outputs represent an amalgam of TOGAF-grade information gathering and SAFe-centered focus. During a Digital Transformation, stakeholders might include C-suite members, a product team, enterprise architecture even procurement. And when technology is discussed what artifact does each group rally around? What artifact can speak the language of each discipline? The Solution Architecture Quadrant has been solving this conundrum for a few years now.
Clear and concise to all participants, we are finding time and time again this exercise offers a consistent approach to taking inventory of complex ecosystem architectures and inviting conversation from every corner of the organization.
The Quadrants
In what begins as a 50-minute session, we break all enterprise architecture into four entity groups. Touchpoint Applications are systems that consumers (whether B2B or B2C or internal users) are going to come in contact with in order to utilize your business's offerings. TOGAF would look at these applications as sitting between users and business components. Operations Systems are systems responsible for holding business data and allowing businesses to action against them. Again, TOGAF might describe this as the Technology Layer. Enablement Systems are responsible for the safe and resilient transport of data between systems or applications. Enablement systems broker intelligence between these entity groups. We must remember Touchpoint Applications' intent is to collect creatively & privately provide data to end-users. Enablement Systems only exist to route data. But it is Operations Systems where data services a greater purpose - drive business functions. Typical context architecture considers only these three entity groups. However, we have found that there is a final entity group that is often overlooked: Conversation Applications. And while often an enigma to enterprises they undergird most award-winning digital transformations. The Conversation Applications entity group holds any network (whether owned by the organization or proxied elsewhere) that is responsible for the flow of feedback about your brand. This might be brand-to-consumer consumer-to-brand or consumer-to-consumer. Each critical for any brand to understand its place in the market and react to what its customers hold dear. Conversation Applications are a bit of an anomaly in Enterprise Architecture because the data often lives somewhere else - a cloud-based customer care tool, a ratings & review service, or even a social network.
Universal Truths
After having aligned on these entity groups we ask ourselves four critical questions that traverse every piece of software the organization is responsible for. We first asked what the Brand promise is to its customers. And one might ask why a technical system exercise would be so interested in a brand's promise. The answer is simple. Every enterprise has to move at the speed of its promises. What you have communicated to consumers always drives everything else. In fact, the more promises you keep with consumers, the more likely it is they'll become repeat customers. They'll pay your retail prices. They'll engage your loyalty programs. They'll trust you. As trusted partners, we have to hold our clients responsible for the promises that they make and essentially demand infrastructure recommendations that align with their go-to-market strategy. If same-day delivery is a promise you make to your customers then every infrastructure decision you make must support it. In turn, every logistics partner we recommend has to support your same-day promise. This might mean choosing Kafka for order communications rather than intraday batches. This might mean upgrading an IVR system because you're running more radio & television spots. And if you tell your customers "we care", that might mean bolstering analytics tools to increase your feedback loop.
On the topic of analytics, every entity in either quadrant needs clear & consistent synthesis. System insights like performance analytics, application analytics, behavioral analytics, or product analytics all send actionable signals into your organization. Gaining actionable intelligence against millions of dollars in operating expenses is how you guarantee returns on investment. Protecting each system investment from licensing overruns or even underutilization is paramount for not just Enterprise Architects but also Procurement groups.
Truly understanding the pulse of your entire ecosystem means making inroads into predictive & diagnostic analytics tools immediately after implementation. We examine each recommended system not just for performance in the market but also its holistic ability to output clear business intelligence. Bottle Rocket also takes great care to recommend the right team configurations for ongoing monitoring & rapid response as your digital system footprint grows.
Security & compliance considerations are cornerstones of any serious enterprise. Competitive organizations invest in the safety of their data from intake to end-of-life and take even more care in ensuring their methods are adhering to regulations. Early in conversations with customers we also gain a high-level understanding of this landscape for your industry & business. We are seeing more and more organizations making decisions to move towards ISO27001 which means we have to be aware of their overall system migration strategy and when their target milestones are occurring.
An organization's sensitivity to PCI Compliance also plays a huge role in how we design enterprise architecture. Questions around decreasing PCI scope might drive payment gateway recommendations as well as commerce partnerships depending on the number of planned transactions.
We also understand compliance is not always commerce-related. If our goal is to build scalable performance and delightful experiences we should also want them to be inclusive. to that end, we may dive into your accessibility scope as well. Considerations like how promotions are displayed, image placement and even color scheme selection can help ensure your experience is reaching all customers.
In navigating HIPAA compliance we are acutely aware of the challenges with keeping patients informed & engaged while also ensuring the utmost compliance standards. Through the Solution Architecture Quadrant exercise, we can draw attention to the right tool recommendations that offer award-winning experiences while also adhering to PHI standards.
Newer regulations like GDPR, CCPA & Virginia CDPA (the right to be forgotten) drive unique concerns for forward-thinking organizations with intricate partnerships. We have now worked with these considerations across several verticals and can ask the right questions early on to help keep steer your digital transformation in the right direction.
Quality is not "last" on this list - it's the finale. All roads lead to quality. Trust, security, experience - there is not one consideration discussed absolved from requiring quality. Quality is not just about testing. It requires driving towards objective & concise requirements. It also involves building a framework of accountability throughout every program output. A line of code has a degree of quality as does a feature or an entire product. We align early around these definitions and draw in the right stakeholders to help clear a path for what will later drive every decision: KPIs. We can not drive towards quality if we are not first rooted in objective truths and desired outcomes. Our quality practice is unparalleled and their considerations stretch across API design, accessibility, usability, product, and even compliance. These conversations begin early and persist throughout the entire engagement.
The Process
We start with an approachable exercise where we capture touchpoints. This is a low-fidelity exercise where we capture your first thoughts on every system to build a loose context diagram. That ends up driving other artifacts as intricate as a sequence diagram to higher fidelity activities like Build VS. Buy analyses.
- Context: We often get into conversations around licensing, concentration of capital costs, and systems that are nearing end of life. For context, our main goal is to capture the existence of these systems and their status in the current environment. Are licenses up for renewal? Are we decided to slow capital costs over the next few quarters? Is one of our partner systems being deprecated or decommissioned outside of our control? We have this conversation as part of the exercise as well.
- Rise Over Run: The two axes that represent the quadrant are based on Internal/Customer Focus (y-axis) and Input/Output Focus (x-axis). The quadrant's top axes are more customer-focused whereas the bottom portion is more centered around the enterprise. The quadrant's left portions represent software that collects driver inputs. Whereas the right-most axes are responsive systems reacting to inputs from customers - review & response-oriented.
- Flowless: We think less about drawing connections (or flow) between these systems because we believe that indicating connections should be process-based. And while certainly important, these early conversations are intended to drive "capabilities" rather than "features" where you might find specific data flows and sequence diagrams.
- 3 PS: Most enterprise failures can be rooted in one of the three P's: process, people, or platform. Very often, we will informally chart a path throughout legacy ecosystems to see if most of the issues are because of one of the three. Trends towards "Platform" may mean a stronger Enterprise Architecture is required. When leaning more towards "process" we often find gaps in leadership and/or digital maturity. When "people" is the resounding trend we find onboarding or even training gaps.
- Annotations: We then annotate each entity then indicate candidacy for further exploration. This way we're clear in our understanding of long-term contexts, but also clear in our approach for the current pursuit. We want our clients to understand what our scope is and that we understand our targets. And we arrive at these conclusions together rather than in a vacuum.
- Solution Mapping: Finally, we perform what's called a solution mapping for our engagement. Just because a system "exists" doesn't mean it's in our purview to explore deeply. Of 50 systems that we might sometimes only identify there may be 15 that we need to target for replacement, upgrades, decommissioning or often we add new systems as part of our strategy engagement. So we draw a careful map across all systems discussed to clearly outline the scope of the engagement and sometimes even more important - what the scope is not. The solution mapping is then evolved in later discussion from the current state to our critical path state (or future state).
- Participants: While our architects are primary conductors of the Solution Architecture Quadrant exercise we have also seen participants across each of our groups can now guide these conversations where necessary and add fidelity over time to the artifacts. The SAQ is now refined enough that we can pull resources from our Product and Business Strategy teams to help drive.
- Patterns & Providers: On the document, we first draw patterns and or providers. We've noticed sometimes customers will rely on the typical "AWS" callouts. They'll yell out "Salesforce". They'll say "RBS". As AWS practitioners ourselves we understand AWS has over 200 products & services. AWS is a "provider". So we'll then narrow the exact offering being referred to or the "product". For the SageMaker service, we might indicate on the diagram "DATA SCIENCE PLATFORM: AWS SageMaker". AWS enables the PaaS model so we want to drive towards more specifics. A customer might also call out "Salesforce". And we all know "Salesforce" might mean Marketing Cloud or Experience Cloud or the obvious CRM. We would then drive towards the specific offering being referred to. Our favorite moments are when customers proudly talk about "RBS". When "RBS" is mentioned everyone's eyebrow raises. A stillness sets. A reverence enters the conversation and the Bottle Rocket team is silent. Confused? Well, that's because "RBS" means Really Big System - a proprietary, custom-built in-house tool only used by the customer. We love these conversations because we get to probe and decompose these large ominous systems and to the customer's relief designate its specific industry-recognized pattern - "a pricing engine" for example.
While ubiquitous language might be important to the organization but we try to stick to pedantic, industry terms to make research easier. It also matters to anyone coming into these organizations to understand what purpose each system serves, rather than its internally branded name. - Confidence Builder: Gaining confidence with new customers early is a (rightfully) daunting task. How do we establish an early understanding of complex environments? and keeping our finger on the pulse of existing customer ecosystems.
Conclusion
After completing the solution architecture quadrant we've heard a significant amount of times that it becomes the single most comprehensive document an enterprise has to identify their entire product ecosystem. We feel that from the quadrate. You can identify costs. You can identify evolution maps. You can identify expensive overlap. The idea of the quadrant is to identify together where concentration is currently centered.
In reviewing the final quadrant we may notice that there's a high concentration of development around touchpoints or OpEx spend against operations but little to no spend on enablement or conversation tools. While this may represent a resistance to scale the ultimate goal is that its made transparent.
Our collective responsibility is not to trend an organization in any one quadrant or another but to demonstrate the narrative and to leave room for a new narrative. To identify what's currently true and its effects on both the customer and the enterprise.
We've seen our design team benefit from this exercise all the way to board rooms using its outputs to decide the fate of an enterprise architecture budget. The Solution Architecture Quadrant is a machete in the tall brush of Enterprise Architecture. Download your first Solution Architecture Quadrant starter template and tell us how it works for your organization.
