[Posted by Jeff Scott]
Over the past decade I have consulted with over a hundred EA teams and have seen all kinds of frameworks and models. What I haven’t seen in all these years is a framework that is truly consumer focused. And by consumer, I mean the EA consumer. Who is the EA consumer? They are the people that directly apply EA products and use EA services.
- A CIO using an application portfolio analysis to recommend where the business should invest their IT dollars is an EA consumer.
- An application development project manager using an EA developed technology decision guide to pick the appropriate technology for their project is an EA consumer.
- A business executive using an EA developed business capability map to understand what business competencies can be leveraged to create a new product is an EA consumer.
Given the significant issues architects have on demonstrating value, I am surprised not to see more focus on the actual consumers of EA work products.
Just like in any other business, when your products and services are in demand by consumers you know you have created value. In my corporate life I created and ran a consumer focused organization that included architecture. What was our measure of success? Demand for EA services. When project managers developed project budgets that included funding for solution architects or CIOs were willing to fund architects to develop their technology strategy then our “products” were “selling” and we knew we were adding value.
A four step process will get you started.
- Identify your consumers. Start with listing all your stakeholders. Then categorize them by groups: investors, customers, beneficiaries, partners, and competitors. Customers are only those people or groups that use EA artifacts or engage architects directly. Technically they must do so willingly. If not, they are prisoners not consumers.
- Identify EA’s products and services. EA products are the physical things architects produce and others use. Services are activities that architects engage in to help others. Required activities such as project reviews can only be thought of as a service if project teams have a choice about conducting the review and see value in doing it.
- Map products and service to consumers. Align each EA product and service to the consumer that uses it. You will undoubtedly have a set of artifacts that aren’t being used by anyone and possibly a set of “required” stuff that your consumers (prisoners) would just as soon not consume.
- Align products and services to consumers’ needs. Now you have to think like a business. You have products and services that your consumers want. That’s good. That means they are “selling”. Build more like this. And you have a set of products and services that your consumers don’t want. That’s bad because they aren’t selling. Now the hard part. Your challenge is to figure out how to create only products and services that “sell”, i.e. that your consumers demand.
All of this isn’t easy, but it isn’t rocket science either. Take a day and lock the architecture team in a room with a big white board and get started. With just a little (sometimes painful) self-assessment you can come up with a consumer driven EA framework and start creating architecture that your consumers want. Then, you know you are adding value and so does everyone else.