Enterprise Architecture – Beyond Frameworks and Standards

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
Author: Russell Villemez is an Affiliate of The Feld Group Institute and a Senior Partner at Dialexa.

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.

Photo by fabio on Unsplash

SHARE THIS

Share on facebook
Facebook
Share on google
Google+
Share on twitter
Twitter
Share on linkedin
LinkedIn

More to Explore

Express Interest

I'm interested in getting more information about the attending a workshop.
  • This field is for validation purposes and should be left unchanged.

Express Interest

I'm interested in learning more about The Feld Group Institute Consulting Services.
  • This field is for validation purposes and should be left unchanged.

Express Interest

| LT

I'm interested in getting more information about the LT course.
  • This field is for validation purposes and should be left unchanged.

LT2

TBD

Express Interest

| EA

I'm interested in getting more information about the EA course.
  • This field is for validation purposes and should be left unchanged.

EA8

TBD

Express Interest

| TLD

I'm interested in getting more information about the TLD course.
  • This field is for validation purposes and should be left unchanged.

TLD11

TBD

Russell Villemez

Affiliate, The Feld Group Institute

Head of Technology Strategy, Dialexa – a Feld Group Institute partner

Highly regarded CTO and change agent with IT strategy and enterprise architecture expertise.

Russell Villemez is an Affiliate with the Feld Group Institute and the head of Technology Strategy at Dialexa, a Technology Research, Design and Creation firm that works with organizations on initiatives such as Operational Transformation, Business Growth, and New Venture Creation.

During 17 years in operational roles and 15 years in consulting roles, Russell has worked across a variety of industries in both executive leadership positions and as a subject matter expert. Russell thrives on the scale and complexity of leading major change agendas in large corporate environments.

Recent consulting clients include AmerisourceBergen, the American Automobile Association, Brinker International, Cubic, Equifax, and Cox Automotive. A common thread is the client’s need for strong leadership during a period of change—whether motivated by acquisitions, spin-offs, competitive pressures, or other factors. Clients also benefit from Russell’s expertise in enterprise architecture, agile development, application portfolio rationalization, technology and architecture strategy, as well as business strategy and commercial software product development.

Recognized as a versatile IT executive, adept at solving complex problems with innovative solutions, Russell’s capabilities and achievements span a continuum from business-strategy formation to hands-on IT solution development. His extensive career achievements include pioneering the first use of relational databases in high-volume transaction systems in the ‘80s, applying voice recognition DSPs in public intelligent network services for consumer markets in the ‘90s, and leading large-scale adoptions of open systems, object technology, and middleware frameworks in complex business environments, often in advance of commercially available software products.

Prior to joining Dialexa, Russell served at HP as Enterprise Services Chief Technology Officer for the Americas, leading a global capability for embedded Account CTOs in large enterprises. Russell began his career at Accenture, where he first crafted his consultative problem-solving approach, later honed at A.T. Kearny and the Feld Group. Russell’s deep telecom experience is built upon numerous director and enterprise architect positions at AT&T, Bell Atlantic, Telstra, US West, Pacific Bell, and Sprint, and as V.P. and CIO for WebLink Wireless.

Russell has a BS in Business Administration from Louisiana State University and an MBA from Vanderbilt University. In his spare time, Russell participates in amateur auto racing, and is a driving instructor with the Porsche Club of America.