Architecture as Strategy
The Digital Leader Newsletter — Strategies and Techniques for Change Agents, Strategists, and Innovators
Architecture is not an inspirational business, it’s a rational procedure to do sensible and hopefully beautiful things; that’s all. —Harry Seidler
The Winchester Mystery House, located in San Jose, was built by the widow of firearm company founder William Winchester. Although it had approximately 160 rooms, it was missing something critical — a plan. The house was built without an architect; the widow Winchester just kept adding on to the building in a haphazard fashion. As a result, the home contains numerous oddities such as doors and stairs that go nowhere, windows overlooking other rooms, and stairs with odd-sized risers. Does this sound like your technology systems, data architecture, and strategy architecture?
I have worked with many companies on the intersection of business strategy and technology capabilities. The underlying challenge and frustration of most CEOs are that it takes too long and costs too much to enable new capabilities. Most of the IT budget is devoted to keeping the current systems running, not to building new capabilities.
(The Winchester Mansion in San Jose, CA, with ~161 rooms built by Sarah Winchester. “She did not use an architect and added on to the building in a haphazard fashion, so the home contains numerous oddities such as doors and stairs that go nowhere, windows overlooking other rooms and stairs with odd-sized risers”1)
I often refer to their IT or technology architecture as the “Winchester Mystery House”—lots of point applications, lots of interfaces, but no master plan or architecture. When you need to nimbly enable a new business model or innovation portfolio, you realize how rigid and brittle the technology applications and infrastructure is. You face the real challenge of innovating and growing. It isn’t winning customers, the real challenge is being able to change in a fast and affordable manner.
Technology architecture—designing data, software, interfaces, APIs, networking, and infrastructure—takes a plan. If you build solely to the point solution (perhaps your specific scenario needs), you are just building another room in the Winchester Mystery House with no eye for future needs. Without a plan, the parts are disjointed and do not create the livability either a house or technology capabilities need. Without a vision, there are two very important things you won’t be prepared for — things to go wrong and tomorrow.
How do you engage your technology partners to create a technology plan for today’s business, your innovation and growth portfolio, and potential future business lines you might not even recognize today?
GET THE -ITIES FROM YOUR ARCHITECTURE
A former colleague of mine used to discuss that technology architecture needs to deliver the “-ities.” The suffix “-ity” means “denoting a quality or condition.” What are the qualities or conditions—the -ities—that the data and technology architectures ideally take into consideration?
• Scalabil-ity: The capability to quickly increase or decrease the throughput or capacity of the system.
• Secur-ity: Keeping out what you want to keep out; keeping in what you want to keep in. Isn’t that security?
• Flexibil-ity: Multipurpose and transformable to different use cases, different geographies, similar needs with variable or conditional processing requirements.
• Interoperabil-ity: Integration and interaction with grace with other types of technology, particularly different brands of technology, and external systems. APIs are one way of creating interoperability for data and processes across an enterprise and enterprises.
• Measureabil-ity: The instrumentation and monitoring capability of the system, to be able to identify, report, and even predict how well things are running and where challenges or failures might be. This can help both IT operations, as well as business processes dependent on measures, such as tolling or billing.
• Usabil-ity: The ease and intuitive interaction between the technology and users. It is the ergonomics and machine-device interface of the technology. Usability also addresses the environmental suitabil-ity of the technology to the operating conditions.
• Traceabil-ity: The ability to track, audit, or explain how transactions, decisions, and systems processes have occurred. “Reconciliation” is not sexy, but with Sarbanes-Oxley and other legal requirements, the ability to show how steps happened across the entire enterprise, often from a “cash-to-cash” perspective, the ability to demonstrate that all transactions happened as they should have happened, is the essence of “control.” As more automation and machine learning are utilized, creating transparency and demonstrating how decisions are made is an aspect of traceabil-ity.
• Extensibil-ity: The essential quality of being able to efficiently meet future business needs with as minimal cost, time, and effort as possible.
• Reusabil-ity: An element of extensibility, the quality of using the same technology for multiple purposes. Modularity, object-oriented design, and appropriate abstraction are all approaches to create reusabil-ity.
• Integr-ity: In distributed architectures, where data and technology are running over multiple data centers, multiple cloud zones, and wide geographies and locations, the quality of having consistency and trustworthy authenticity, especially with data that has to be correct and have authority. The traditional example of an “atomic transaction” in which either all aspects of a transaction successfully commit to the distributed database or the transaction rolls back is a key now being augmented with the concept of “eventual consistency” in which the valid value for data is eventually made across all distributed versions of the data.
• Modular-ity: Creating discrete, well-defined, and separated functions of capabilities in software. A solution typically integrates multiple module services together. An important strategic notion at Amazon is that modular services need to be “self-service”—that is, to use your capability, someone should not need to talk to you to understand, design, test, deploy, or operate your service. This helps not only scale the technology but scale the organization.
• Qual-ity: The notion of a system doing what is expected. In technology, key enablers include the ease of being able to test and verify, deploy, manage versions, and effectively deal with software bugs.
• Stabil-ity: The ability to deal with new requirements and operating dynamics while not affecting the underlying architecture. Proper abstraction in the architecture design is the key to achieving stability. In the physical environment of computers, networks, and data centers, stabil-ity also is reflected in redundancy, failover, and disaster recovery scenarios.
• Availabil-ity: The ability to respond immediately. As ESPN football analysts often say about athletes and injuries, “the best ability is availability.” In retail, if an item is not available, you’ve lost an order and often lose the customer. In technology, it is no different. Systems must be available and deliver the response times required by the user and business. Near-real-time (NRT) systems in which there is minimal lag are critical architecture notions (neither cheap nor easy) that enable many digital experiences.
BEZOS’S API MANIFESTO
In 1999, Barron’s printed its now classic cover story “Amazon.bomb,” which predicted that Amazon’s stock was going the way of Pets.com and Drugstore.com. But instead of becoming a disaster, Amazon turned the corner from a market confidence standpoint, and it grew to become one of the “four horsemen of tech.” It wasn’t long after Barron’s cover story that we began recognizing that Amazon was really two key types of businesses.
First, of course, we were a broad, multicategory e-commerce retailer. At the time, played a leadership role in launching the Marketplace, or as we referred to it, the “Merchants at” or “M@” business. M@ was critical to creating “the everything store.” Using the M@ platform, we opened over 14 categories, such as apparel, sporting goods, musical instruments, gourmet, and jewelry.
However, it was around this time that Amazon began seeing itself as a platform company, serving many other companies in addition to being Amazon the retailer. We decided that all systems needed to interoperate, internally and externally, through APIs. These APIs needed to have hardened interfaces, which meant they were well-architected, not prone to sudden changes, and were forward compatible. APIs had to have SLAs measuring against a set of performance standards for speed and availabilities. And SLAs had to be fault-tolerant—that is, they needed to assume that other dependencies might fail or degrade. Regardless, the APIs had to process gracefully in a situation where other system components were not operating properly.
Like any big change, the technology was difficult, but getting people aware, committed, and all going in the same direction was the big hurdle. In Bezos’s classic clear communication style, this memo in 2002 contained the clear commandments from the top of the mountain.
Steve Yegge, a former Amazon engineer, recalls the memo in this classic blog post2:
His Big Mandate went something along these lines:
1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no backdoors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols—doesn’t matter. Bezos doesn’t care.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn’t do this will be fired.
7. Thank you; have a nice day!
Ha, ha! You 150-odd ex-Amazon folks here will, of course, realize immediately that number 7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day.
Number 6, however, was quite real, so people went to work. Bezos assigned a couple of Chief Bulldogs to oversee the effort and ensure forward progress, headed up by Uber-Chief Bear Bulldog Rick Dalzell. Rick is an ex-Army Ranger, West Point Academy graduate, ex-boxer, ex-Chief Torturer slash CIO at Walmart, and is a big, genial, scary man who used the word “hardened interface” a lot. Rick was a walking, talking hardened interface himself, so, needless to say, everyone made lots of forward progress and made sure Rick knew about it.
Through their architecture, Amazon set upon both scaling their internal organization, as well as their business model. Today, Amazon has hundreds of public APIs, everything from product-related APIs to AWS APIs, Echo APIs, and APIs in their fulfillment network through Fulfillment by Amazon.
Their architecture allows them to reuse and more nimbly react to a new market condition or initiative. Their architecture is a critical strategic capability to stay nimble and continue iterating.
“HELP ME HELP YOU!” — Actions to Take
Who can forget the classic Jerry Maguire scene where the sports agent has a heart-to-heart with his player, Rod Sterling, in the locker room after the game? The agent is pleading with the player to do some things differently, to make it easier for the team to offer an extension to his contract. “Help me help you!” Maguire begs. How often do business people simply turn to their technology team and basically say, “This is your problem, nerds”? If you’re going to win in the digital era, being a better business partner and collaborator with your technology team is critical.
What’s your role as a business partner to your technology team?
First, care about these elements, the “-ities” and work with your technology team to articulate how these capabilities are key to the business strategy. Drill down on the use cases, and specify how the factor relates to the customer experience and strategy. Be curious about how these scenarios are supported and measured, and ask a lot of questions on each one.
Second, focus on the long term. You must be willing to figure out how to fund and rationalize what might be up-front costs to enable these underlying capabilities. If the estimates from your technology team or provider seem unreasonable, you need to make this a “business discussion” and engage in the assumptions and strategies leading to the estimates. What are the drivers and alternatives? What are the different approaches, such as starting with a fresh software stack, which might enable more speed and flexibility for your strategy?
And third—and here’s where your architecture becomes your strategy—go on the offense. How could “architecture capabilities” be leveraged into an additional business opportunity? For example, how could either internal or external entities leverage the architecture “as-a-service”? There are many companies that have gone this path with Amazon being the primary example. Leveraging self-service capabilities and APIs, build a capability enticing enough that it is the fast path for others to use. If you can envision and articulate that your offering is better than the alternatives and who your early target customers would be, then funding the -ities can be moved from the “overhead costs” to the “direct costs” column. The architecture is now becoming the business — a revenue engine!
You’re likely not the technical architect, the software developer, or the CTO of the organization. As a business person, the change agent, working to innovate and make change happen, you need to be curious and current on these key technology concepts and be a better business partner to your technology leaders. Everyone needs to raise their technology understanding to innovate and drive growth.
What are the “-ities” you need to support not just today’s concepts but help the organization to become faster at innovating?
About The Digital Leader Newsletter
This is a newsletter for change agents, strategists, and innovators. The Digital Leader Newsletter is a weekly coaching session with a focus on customer-centricity, innovation, and strategy. We deliver practical theory, examples, tools, and techniques to help you build better strategies, better plans, better solutions — but most of all to think and communicate better. You’ll be able to follow up with questions and advice.
Please share with others! Thanks
https://en.wikipedia.org/wiki/Winchester_Mystery_House
https://nordicapis.com/the-bezos-api-mandate-amazons-manifesto-for-externalization/