In Part 1 I discussed the shift in mindset for Enterprise Architecture (EA) Practices from a goods-centered view, considering EA development as a product, to a service-centered view, considering that value is co-created with the client/customer. I also showed this Lean Canvas for Enterprise Architecture Practice as an example of a way to look at an EA Practice as if it were its own company, working to deliver value to its “Customer Segment”. I encourage you to get your own Lean Canvas for free at leancanvas.com and fill it out for yourself. Think about how you can more directly engage those to whom you want to deliver value.

Value is created in the Customer Segments and Early Adopters box, the Problem and Existing Alternatives box, and the Unique Value Proposition box. The key is knowing and validating the problem you solve (jobs-to-be-done) for each of your Customers (people who pay you money). Value is delivered through the Solutions box and the Channels box. The key metric is the Unique Value Proposition box and the Revenue Streams box. Make multiple canvases, maybe one for the whole practice, and then one for each key stakeholder. Lean Canvas is geared toward startups and I believe the EA Practice is just that.

Customers (and employees) are human too

A shift in focus to a service-centric perspective might be a nice thing to do, but at the end of the day does it make an impact? This, and other questions are answered in the culmination of research done by the Gallup organization on managing the customer-employee encounter, Human Sigma (Fleming & Asplund, 2007). This book lays out the case for employee engagement, customer engagement, and the amazing synergy that occurs when you work on both at the same time.

“In a recent study of 89 companies, we found that the companies that built this critical mass of engagement grew earnings per share (EPS) at 2.6 times the rate of companies who do not.” (Fleming & Asplund, 2007) Signaling the move to value creation at the employee-customer encounter, Fleming and Asplund call it the new “factory floor”. Of course their explanation that an emotionally engaged customer spends more with a company than a merely satisfied customer is aimed at the commercial firm in total. However, understanding the difference, and putting to practice the insights from their study can only improve the standing of the EA Practice in an enterprise.

The whole idea of focusing on the customer encounter might not be the forte for the average Enterprise Architect. Common anecdotal evidence suggests that EA Practitioners like to work alone, create elegant solutions with little regard to deadlines, and are in general, a prickly kind of person. Executives like the skills architects have, and often don’t like the way they come across.

The impact of innate preferences on practitioners

Commonly observed frustrations with EA Practitioners may be understood as behavioral expressions of the preferred Jungian personality type of people attracted to EA Practice. These behavioral expressions can tend to alienate the executive champions needed for continued political support of the practice.

As indicated through multiple instances of research, technical professionals tend to cluster as NT types, as indicated via the Myers Briggs Type Indicator. Further, David Keirsey (Keirsey, 1998) calls the INTP “The Strategic Architect”. According to their type description, INTPs like to work by themselves, focusing on an inner world of thinking, perceiving the outer world through intuition. Their perceiving preference tends to hold off decision making, while they work on many variations of scenarios in an endless search for a right answer. They value competence and may be irritated by others they do not believe measure up to their standards. They continue to seek elegant solutions while not actually delivering information to decision makers because they haven’t yet covered all the scenarios. They are quick to point out variances from their optimum solution as wrong, even though they may have never communicated that strategic picture.

Understanding these behavioral expressions of preferred type and teaming them with complementary typed people, may make leveraging their value easier socially and politically. Adding the understanding of a focus on the individual strengths of an Enterprise Architect, via the Gallup® CliftonStrengths® assessment and coaching, is the best way to encourage employee engagement. Understanding the psychological type and individual strengths of members of an Enterprise Architecture team will enable a team leader to compose a team of complementary strengths, and supplement missing strengths by sourcing them appropriately. The key to making the team function with a focus on customer engagement is a leader who is type and talent aware.

A move away from the G-D logic based creation of an Enterprise Architecture “product” to a S-D logic, service-centered mode of operation will call for constant conversation and interaction among the EA Practitioners and their stakeholders. It will call for a moderation of the desire on the part of the Enterprise Architect for the solution to be technically optimal, and will lead to a more rapid sub-optimization based on the requirements of the stakeholders who are brought more closely into the architecture development process. The client will take the role of the designer, and the architect will more appropriately support the design. The Enterprise Architect might also have knowledge of other developments or strategies that might impinge or enhance the needs of the client organization. In any case, the Enterprise Architect will need awareness of the behavioral expressions of the perception and decision making preferences that make them so effective as EA practitioners, so that they can moderate them to ease the give and take with their stakeholders.

Conclusion

TOGAF ® (The Open Group, 2011) recommends that the EA Practice in an organization be created and managed as a distinct business entity. Its wording and approach to Stakeholder Management can lead to objectifying stakeholders, rather than encouraging a closer, more engaging relationship. Employing a service-centered mind-set and a customer engagement focus will enhance the brand of the EA Practice in a firm. Understanding that value in Enterprise Architecture Practice is co-created by the architect and the customer will make the transition to a customer engagement focus clearer in the minds of everyone.

Recognition of the shift in locus of value creation should affect the way architects are measured as employees. Creating an environment of employee engagement through Leadership Development and Coaching will enhance the synergy of the architect -customer encounter. Individual Leadership Development and Coaching will help architects in their interactions with executives and enhance their career movement to executive roles as well.

Note: Gallup® and CliftonStrengths® are trademarks of Gallup.

Works Cited

Fleming, P. J., & Asplund, J. (2007). Human Sigma - Managing the Employee-Customer Encounter. New York, NY: Gallup Press.

Keirsey, D. (1998). Please Understand Me II. Del Mar, CA: Prometheus Nemesis Book Company.

Lusch, V. a. (2008). Toward a conceptual foundation for service science: Contributions from service-dominant logic. IBM Systems Journal , 47 (1), 6.

The Open Group. (2011). The Open Group Architecture Framework (9.1 ed.). Reading, U.K.: The Open Group.

Vargo, S. L., & Lusch, R. F. (2004). Evolving to a New Dominant Logic for Marketing. Journal of Marketing , 68, 1-17.

It has been tradition that an Enterprise Architecture (EA) Practice has managed itself in the traditional manufacturing goods-centered way that has been common since the onset of the industrial era. This causes the architects to focus on the wrong point of value delivery to satisfy their clients. Changing the game by managing itself as a service-centered business in its own right and changing the locus of value creation to the architect-client interaction will change uninterested clients into raging fanatics.

Introduction

Enterprise Architect Practices in many organizations struggle to remain relevant and even to remain in existence. Practice leaders struggle with reporting structures and continued proof of return on investment for the headcount and funding to maintain the practice. Finding a champion in the executive ranks helps the cause, but why aren’t the stakeholders demanding the permanence of the EA practice that is supposed to advocate for their requirements? What is the value of having an EA practice? Or to be more precise, where is value created by an EA practice? Common management measurement practices have their origin in the beginning of the Industrial Revolution. These measurements are rooted in what is termed goods-dominant logic (Lusch, 2008) where goods are created away from consumers who diminish the good’s value through consumption. Employee measurement became based on how many “widgets” were produced. Value is created away from the customer in the manufacturing site. The EA practice has waited to receive a “request for architecture work” and then engaged to “manufacture” architecture artifacts, creating an architectural representation to be presented back to the client. This goods-centered approach has created a customer requirements dissonance, and often less than satisfactory results in the viewpoint of the client. Architects are commonly measured on the number of artifacts they produce and the timeliness of their delivery.

The EA practice should be organized as a service focused business (entity) within an enterprise. As the EA practice delivers a service it should be measured through application of service-dominant logic (Lusch, 2008) where value is co-created at the point of service between the architect and the client. As such, the relationship between the architect and the client should be understood, measured and managed as interdependent. Ideas of customer satisfaction need to acknowledge the emotional component of these relationships in addition to the impact that necessary information for decisions is delivered in a timely manner. Practices to encourage customer engagement with the “brand” of the EA practice should be developed along with the feedback mechanisms that encourage them.

An overview of goods-centered and service-centered concepts

The Industrial Revolution brought economies of scale and standardization to the production of goods. The field of economics soon picked up on the paradigm of goods manufacturing, placing emphasis on the possession of raw materials (wealth) and the transformation of raw materials into goods to be sold. The fundamental concepts that emerged from this goods-centered view were:

1. “The purpose of economic activity is to make and distribute things that can be sold.

2. To be sold, these things must be embedded with utility and value during the production and distribution processes and must offer to the customer superior value in relation to the competitor’s offerings.

3. The firm should set all decision variables at a level that enables it to maximize profit from the sale of output.

4. For both maximum production control and efficiency, the good should be standardized and produced away from the market.

5. The good can then be inventoried until it is demanded and then delivered to the consumer at a profit.” (Vargo & Lusch, 2004)

Personnel Management concepts soon followed in this goods-centered view, with notions of value exchange between workers and firms being the provision of labor at the lowest cost to maximize the profit of the finished good. Ideas such as attendance-based compensation, where workers were considered “interchangeable parts” that were paid to show up and perform tasks as they were instructed, soon followed.

As work became more specialized and based on information in the later half of the 20th Century, notions of services delivery as products to be sold followed the goods-centered view of industry. Marketing ideas of customers as physical resources to be “Segmented” and “Sold to” followed this view as well, and drove business strategy and marketing development.

It is not surprising that Enterprise Architecture would be organized and carried out in this goods-centered world view. “Requirements” are raw materials to be gathered from “Stakeholders”, and out of sight of these consumers, raw materials (Requirements) are transformed through the Architecture Development Method into “artifacts” and “Deliverables” that are returned to the “Stakeholders” under contractual obligation.

Progress in Economics with this goods-dominant logic came in the form of trying to make the theories into Science. Economists along the way tried to account for services in a firm as “intangibles”. The literature points several times to the inadequate nature of this treatment, particularly as work became more specialized and many jobs were carried out internally with no connection to the manufacture or distribution of goods. A service-centered view emerged as recognition of a “service economy” grew. Research has shown that standard economic practices cannot account for as much as 80% of market value of the average S&P 500 company, labeling it as “intangibles”. (Fleming & Asplund, 2007) Perhaps they have the valuation backwards!

In the service-centered view, or service-dominant logic (S-D logic) the locus of value shifts from being embedded in the goods to being delivered at the point of contact with the consumer. In fact, value is co-created with the customer as value-in-use of the service. This is not to be confused with the sale of “Services”, as in the idea of Consulting Services, but more the idea of Jobs-to-be-done for which a solution is created.

The primary unit of exchange in S-D logic is knowledge and skills, rather than goods. Goods become an appliance in the delivery of service. This difference is exaggerated in the adage. “People don’t buy a drill to own the drill, they buy it to own the holes.” Interactions between the firm and customer become crucial in S-D logic because relationships are key to a self-reinforcing value cycle. In this cycle, needs come from the customer, and the firm delivers highly customized knowledge and skills. Cash flow is the measure of success of the firm’s value proposition. An example is hours of jet engine performance which include an engine and all maintenance provided by the manufacturer.

In the service-centered world, firms differentiate themselves by their value propositions. This notion fits well with concepts of movement from “value-chains” to “value-networks”. The recognition of value networks makes ideas of competition and partnering different as well. A competitor may be a collaborator as well, as value propositions are combined to satisfy customer needs.

In service-dominant logic, the EA practice behavior looks very different. Every interaction with a stakeholder is the key to value delivery. A value proposition to deliver strategy, supply guidance for decisions, and supply other special knowledge and skills might be a good starting offer. To accomplish this change, the EA practice needs to think of itself as its own firm and the stakeholders and executives as its customers. The practice’s value proposition needs to be carefully tuned and continuously adapted. Customer engagement becomes critical to the practice.

Works Cited

Fleming, P. J., & Asplund, J. (2007). Human Sigma - Managing the Employee-Customer Encounter. New York, NY: Gallup Press.

Keirsey, D. (1998). Please Understand Me II. Del Mar, CA: Prometheus Nemesis Book Company.

Lusch, V. a. (2008). Toward a conceptual foundation for service science: Contributions from service-dominant logic. IBM Systems Journal , 47 (1), 6.

The Open Group. (2011). The Open Group Architecture Framework (9.1 ed.). Reading, U.K.: The Open Group.

Vargo, S. L., & Lusch, R. F. (2004). Evolving to a New Dominant Logic for Marketing. Journal of Marketing , 68, 1-17.

Subscribe now

Enterprise: The whole of a business, company, corporation…

Architecture: The classical consideration of a structure, and its constituent parts, and the parts relationship to one another.

That aught to clear things up. In all of my years working in the profession of Enterprise Architecture (EA) for a large tech company, toiling on international standards, and teaching hundreds of Enterprise Architects, the question of what Enterprise Architecture is was sure to start an intense discussion. So my definition is practice based. EA bent the heads of technical leaders who had made their careers with technical expertise, to an artistic consideration of where technology, business, and people join.

Over the years I have been asked one question often: “Our EA practice is starting, what should we do?” And here is my answer. There are two things that need to be accomplished at a broad level:

1. Put the enterprise’s treasure where its heart is.

2. Align the results of the architecture work with the budget cycle.

Every company was started for a reason. The founders had an idea about how something could be done better through innovation. What that something is can be found in the elevator pitch you give at a social gathering when asked what your company does. Yet every year at budget allocation time, money and people are divided up for projects to redo or remake parts of the business that have no, and I mean NO, connection to that core business. This is true particularly if the company has been in existence for a while. These diversions of hard earned capital are often justified by the “but we’re different” bias, or the “we’ve always done it this way” bias.

So the first job when you come in as Chief Enterprise Architect, or something similar, is to pare down and eventually halt the bleeding of money away from the core business. The next cycle for each function that is not core is to instantiate standard business processes (see APQC (American Productivity & Quality Center)) and packaged software or outsource solutions that will support them. Put your logo in that software package and do no other alterations. Gradually focus the money the company spends on its core business, and innovating on that core business, because I guarantee you that a three person startup team is aiming their project at your company .

The second job, and it’s necessary to get the first job done, is to discover and map the real budget process cycle and who the players (stakeholders) are. Your job is to deliver the information needed to help the decisions at each stage of the budget year, when that decision is being made. For example, one company I know had a “Spring Plan” and a “Fall Plan”. The Spring Plan gathered the next year’s budget requests, there was a period of research and then the Fall Plan finalized the budget for the following fiscal year. Find each stakeholder, determine what information they need by a deadline, and count backwards the amount of time needed to create the architecture work for that decision point. This will set the cycle of architecture work for the team.

Do not be late with the information. If you are late, keep the information to yourself, or at most, deliver any critical discovery verbally. Your stakeholders may have fiduciary responsibility to the company, and if you dump new information in writing to a principal decision maker after their decision, then a legal argument can be made that critical company decisions were made without due diligence. This could be a bad thing.

Each EA practice should operate as its own company in a company. Your output is a service, actionable information, not an architecture artifact. You need to make a mafia offer to the decision making principals about delivery of the two outcomes I described, so that you have a defense from being pulled into a meeting on how to rewrite the payroll application for the fifth time. But more on this in another post.