Most EA practices are adequate. A select few are outstanding. Some are downright beacractic and frankly not useful. So is there a secret sauce for making EA outstanding?
It’s About Focus
EA’s secret sauce is neither a secret nor a sauce– it’s all about focus. Many EA teams (like their business department brethren) grew organically with dynamic offerings and ever-changing roles to “meet the dynamic needs” of the business. However, this creates fuzzy stakeholder understanding of EA, and spreads enterprise architects too thin.
EA must be run like a business. That is to say, EA requires a clearly-defined customer base, a set of relatively standardized products and services, and a set of success measures. Finally, EA’s metrics and recent wins should be thoroughly socialized via cadences which not only communicate the metrics driven from EA but serves as a marketing channel to convey the value of EA itself.
Defining Where to Play
Are you playing football, or are you playing tennis? This may sound ridiculously simple, yet it’s a question many EA teams cannot succinctly answer. Defining where to play is part of a winning aspiration and essentially defines your playing field.
Put simply, EA needs to ask itself: where should we focus? The business may be growing and thus needing attention in SG&A / go-to-market domains such as sales and marketing. Or perhaps the company is focused on reducing G&A / OpEx costs and thus needs optimization transformation.
Defining where to play means being able to intelligently answer where EA will focus. If EA simply “works across the company” or “often works with all business units” there may be a scope issue to address.
Defining EA’s Customers
Who are EA’s customers? If you answer with a response such as “all business leaders” or “key enterprise process stakeholders” then you may be sent home with a consolation prize of ultra-thin spread EA value.
In the spirit of running EA like a business, let’s actually look at some business strategies. Whole Foods targets affluent shoppers, while Walmart targets cost-conscious consumers. XBox (Microsoft) targets hard-core shoot-’em-up gamers while Nintendo captures family-friendly gamers. The list goes on, but the takeaway here is that EA should be able to articulate customers by name or role.
Common examples of EA customers are the CIO (typically customer #1), CIO direct reports (VPs of data, infrastructure, business applications, etc), CIO peers such as the CMO, and perhaps a few select additional leaders such as the chief privacy officer, chief security officer, and so on.
Define EA’s Products and Services
When we think about Tesla, we think about electric cars. With Starbucks, it’s all about coffee. When your (well-defined) customers think of EA, what do they think of?
While I’m not advocating for an overly-standardized factory IT model here, I am asserting that the thought of EA should be equated to a set of products and services. EA deliverables must not be subjective from customer to customer.
Common examples of EA products and services include:
- The enterprise architecture repository— the place to find an up-to-date representation of the enterprise in terms of business process, applications, data, and infrastructure.
- Standards and principles – Artifacts that document what technology and processes business units should for various needs
- Various solution architectures – For example, clear definitions of what the CRM, ERP, and ESM solutions look like
- Consultative services – Well-defined consultations for pre-project assessments and/or vetting of vendor-proposed solutions.
The list can be much more expansive of course, but this is just an example of how to create some degree of standardization of EA products and services. Standardization ensures that EA success is measured in a consistent manner, and again, provides a repeatable experience for EA’s customers.
Define Success Measures
How does EA know if it’s winning or losing? Whether you refer to them as success measures, KPIs, or OKRs; it really doesn’t matter. EA needs some type of measurement to gauge overall success.
Common examples of EA measures include dollars saved, customer satisfaction, and architecture due diligence rate (i.e. how well the enterprise is conforming to standards). The goal here is for EA to be measured in a fair and consistent manner as we do not want success to be in the (subjective) eye of the beholder/customer.
Tying It All Together With Cadences
There’s a continuous cycle of input to EA, and output of results. Input is engagement with EA, and represents EA demand. Output is effectively EA’s products, services, and the quality thereof.
When to engage EA is important. Just as you cannot stroll into a Starbucks at 2AM, there must be some guidelines for when to engage EA. These can be chokepoints within the company’s SDLC (“project intake”), the software request process, or RFPs just to name a few.
The value of EA, articulated through success measures, must be thoroughly socialized in an outward manner to all customers. This can be achieved through QBRs, newsletters, and intranet portals.
This is nothing new for business units. Marketing teams socialize campaign success, finance teams tout cost savings, and HR applauds rapid time-to-fill metrics. If EA wants to be a part of the business, it needs to act like part of the business, which means maturing measures and transparently socializing them with customers.
Summary
Productizing essentially means taking something and making it more familiar to consumers. We’re all consumers, and we’re all familiar with products as we’ve been using them since childhood.
Productization has its roots in product management, but suffice it to say that for EA, the goal here is to pivot EA away from a functional organization into a product-focused organization. That means having a roadmap of products (perhaps with “features”) and of course services. It means making the user experience consistent, predictable, and user-friendly. It means focusing on the customers EA can delight, while divesting customer bases better served by other means.
Finally, productizing EA is not just what’s best for the customer. It allows EA to focus, which prevents both the practice and architects themselves from being spread too thin. This can ensure a sustainable EA practice with happier architects over time.
