In his ongoing series about Thriving in Dynamic Times, Charlie Feld recently wrote about the importance of Architectural Principles and Architectural Outcomes. In that article, he emphasized the need to “make the call” – avoiding endless debates on architectural decisions and getting on with the business of implementation.
But once enterprise architects have made the call, do they have the kind of influence with development teams needed to drive the “right” business outcomes? Unfortunately, in some cases, that is precisely the problem. They are either not empowered, not willing, or not able to exert the appropriate amount of direction and influence in the design and build phases and end up mostly talking down to the development teams from the proverbial ivory tower.
One might imagine that this is mostly caused by the “unwilling” dynamic. But if you think about the problems that most enterprise architects grow into as they mature in their careers, a different picture emerges.
ARCHITECTURE AT SCALE
Most of my fellow enterprise architects started their careers in roles within software engineering, data engineering, and infrastructure engineering organizations. As mostly engineer types, we are very problem/solution-oriented. We see real-world business problems and come up with real-world technology solutions. After establishing competency in a particular specialty (within software, data, or infrastructure, for example), many then graduate to become Solution Architects, working as business and technical generalists in the design and construction of specific, localized business solutions. These jacks-of-all-trades are some of the most valuable people in your organization, and the leadership challenge is making sure that this scarce resource is working on the “right” local solutions.
As we continue to grow in our careers, and as our responsibilities expand, we move from individual problems and solutions to collections of problems and collections of solutions. We see problems that span and/or repeat across multiple business units, multiple functional domains/capabilities, multiple value streams, and all kinds of technical domains: security, data-in-motion, database and storage options, hosting options, the list goes on and on. Eventually, at an enterprise scale, we end up seeing THE problem as thousands of randomly selected and localized technologies, wired together in brittle and inconsistent ways. We see the world as the result of too many years of unmanaged chaos – at scale.
We think the solution to this problem is to fill in the missing structural constructs that could have prevented that chaos. So naturally, we design elegant taxonomies, frameworks, and reference architectures that place each of the thousands of fragments into named domains, in perfect alignment with each other. Then we publish standards for each domain and erect Technology Review Boards to maintain order in what would otherwise devolve into chaos again. Problem solved. Top-down order out of chaos. At scale.
BUT WAIT, THERE’S MORE
At the same time, unless your business competes purely on leverage-at-scale, or on well-ordered IT portfolios with minimal messiness, this is not enough. The translation of business strategy into technology strategy also depends on the ability to drive specific outcomes out of local solutions. And more often than not, the business leverage that really counts doesn’t happen uniformly across the business. It happens in very specific pockets of the business model. In those specific pockets, it is critical that the strategic architecture is APPLIED APPROPRIATELY.
This is where enterprise architects need to dive in and provide DESIGN-LEVEL guidance and influence to ensure what I call “pivotal design outcomes”.
These are the areas where enterprise architects have to zoom in, get their hands dirty, and help individual development teams design their solutions towards the needs of an enterprise-level goal. For more insights on the traits of great architects, including the ability to zoom in as well as zoom out, see Mike Childress’s article called “Common Traits of Great Enterprise Architects”.
PIVOTAL DESIGN OUTCOMES
Opportunities to zoom in on pivotal design outcomes are in large part rooted in the manner in which strategic intent is translated into business capabilities, and from there, into solution designs. As a result, they come in many flavors. Even within the same industry. Here are a few examples to consider:
Company A sells to large multinational businesses. Their product portfolio is derived from several years’ worth of acquisitions of smaller companies, so it is bursting at the seams with many redundancies and confusing pricing. They operate multiple billing systems – inherited from each of the acquisitions – and as a result, customers receive multiple invoices. The only thing their customers really want is favorable pricing for high volume purchases. Therefore, product bundling, cross-product discounting, and system-wide pricing are pivotal outcomes.
Company B sells to mid-sized businesses in smaller geographic markets. Their product line-up is small, static, and derived from organic growth from a centralized inventory. Their customers want more variety in terms of product choice, local pricing, and fulfillment cycles due to their high rate of inventory turnover. Customer service representatives intervene with manual workarounds to make the static system produce what seems to the customer like a custom-built order. For Company B, dynamic ordering, dynamic pricing, and dynamic fulfillment are pivotal outcomes.
Company C is a logistics and distribution supplier. (You might even imagine that they move products from Company A and Company B warehouses to A’s and B’s customers). Some products need to move in large lot sizes; some need to move in consumer-ready packaging. Customers require pick-ups and deliveries that range from weekly to on-demand “need it now” time constraints. Company C’s pivotal outcomes are dynamic assignment and routing of transport assets and real-time, dynamic assignment of shipping containers to transportation assets.
Each of these companies has their own version of chaos at scale. And so, Enterprise Architects are zooming OUT and creating enterprise-scale guidance for all development teams. However, each of them also exhibits company-unique needs for pivotal design outcomes that have capability-specific technology implications:
- They each have a need to use rules engines to address all of those design outcomes that start with the word “dynamic”.
- Each needs data hubs to address outcomes that require real-time reaction times, cross-functional insights or system-wide enforcement of product or customer domains.
- And each needs channel services that abstract the nuances of geography, customers, partners, and engagement modes from the business logic.
How each of these is designed for implementation varies greatly across the examples. There are no one-size-fits-all implementations for any of those technologies that work in every company. The only repeating pattern is that each implementation has enterprise or cross-functional impacts that need the perspective of Enterprise Architects.
And so, Enterprise Architects at these companies must zoom IN and be involved in creative problem-solving at the solution level, tackling various design challenges in the APPROPRIATE APPLICATION of data hubs, rules engines, common event models, omnichannel services, machine learning, IoT, distributed ledger technology, and a myriad of other technologies.
CONCLUSIONS
- If enabling business agility is the #1 objective of architecture, Enterprise Architects should see and seek more involvement in design work. Not every design of every solution of course; but certainly, design for those elements on which the business must pivot with the most speed and least amount of friction. We should be looking to participate in those areas where the benefits of leverage are maximized, and where speed of change is central to the business strategy.
- It’s important to reiterate that these pivotal design outcomes are rooted in the business model and in the downstream translation into business capabilities and solution designs. Yes, it’s important to have a radar-like sense of when and where various technologies are ready for specific applications within the IT landscape. However, EA involvement in the design challenges of specific solutions should occur at the nexus of both top-down business outcome guidance and bottom-up tech radars.
- Enterprise Architects have to be more nuanced on how to play against both scale and design problems at the same time. For example, getting all of your architects to line up in support of the chosen rules engine (making the call) is a good thing. Leveraging that rules engine for every last business rule in the enterprise is not. As you step out of the ivory tower to zoom IN, discernment over enforcement is a good trade-off.
- Enterprise Architects need to retain the original design and problem-solving skills that got them into the field of architecture to begin with. In the case of solving chaos at scale, EAs will need to design and implement solutions that development teams consume. In the case of pivotal design outcomes, they will need to help teams with their own local designs, for the benefit of the enterprise. Either way, they have to go beyond “making the call” and be intimately involved in getting on with the business of implementation.
Dialexa builds the world’s preeminent technology solutions. We are the arsenal behind the world’s largest and most successful companies, building revolutionary technology products that solve today’s complex business challenges. Please contact us if we can assist with your digital transformation or data science needs.
