Cheers
Scott

My understanding is that the the reference architecture should provide abstractions to solve the problem, but use an adapting pattern to bring in the current technical choices.

E.G. ‘Abstract Layer’ might be shown as ‘Persistence Subsystem’, extended by Hibernate, .NET Entity Framework, etc.

In such a climate, if EA retreats into the budgetary protection of IT, it will be expected to carry a share of the IT “load,” at IT leadership sees it. But the stream of expectations are still coming from the business, who have already, a priori, written EA off as about technology, not things of uniquely business substance. Game over, really, for “EA” as it could be. EA becomes a euphemism. Technologists stream into the discipline, rise to the “top”–and sit there, hoping to participate in the “real world” they are supposedly paid to help.

In the actual business of powering the enterprise value proposition, business managers who are unable to effectively perform are sometimes pushed to the side (when it is too expensive to do otherwise). This is all normal business protocol; but enterprise change agents who happen to be sitting in IT are sometimes mystified.

Imagine this: a business unit takes on someone who cannot actually do the work there. I mean, the new person is a brother in law who was strongly “recommended.” Yet, the day to day work must get done. This is a real political tradeoff that won’t go away and can’t be protested. Answer–quietly put them on the margins of the real work, hopefully not resulting in a net productivity loss for the unit, while saving face, until something happens to sort it out.

It’s a purely political strategy because it’s a necessary, though potentially risky, compromise. The risk mitigation is to find a net productivity adding solution and hope for the best. The point is this: Enterprise Architects cannot be foisted on the business or they will suffer the same fate. At best they will be tolerated and the perceived risks mitigated.

IT knows this scenario well. Sometimes IT signs on to put a few “interns” on a project–or whatever. The problem is the same as for the “business”: find a net productivity gaining solution and hope for the best. Ask a team lead what they think of the idea.

If the EA “position” is institutionalized and it is perceived as a net positive only with watchful risk mitigation, it is a sitting duck for the next budget tightening, just like anything the business believes it can no longer keep around. What about all those models and all that work and the “investments” in people, processes, and technologies? Sunk cost. To business executives who must “cut their losses” in hard times, an “investment” is capital, not cost. Capital generates value; cost that does not support value is not an investment.

Senior executives who participate in LSS get Peter Drucker’s observation that “nothing is less productive than to make more efficient what should not be done at all.” In LSS, you 1) select processes for LSS optimization based on prior and purely business criteria; 2) drive latency/waste out of the selected process based on structural analysis of the process and its business environment (kaizen opportunities to improve); 3) anything that requires a project to fix. Senior business executives get the idea that waste and rework is costly. They also get the idea that not every fallen penny is worth rescuing–some things are more important to the organization’s value proposition than others.

If Enterprise Architects are to be taken seriously by the enterprise, they must react to what threatens the enterprise value proposition. Gee whiz obsession with the latest “techie thing” will of course result in marginalization. They must be seen a serious business partners. And that may require suppressing their desire to wave the (what will be perceived to be a) “here’s another silver bullet” flag in the presence of people who are not impressed (for long).

People are not just one of the elements of architecture. They are not part of a “technique” to include and appease stakeholders. People are the primary lens through which the enterprise is perceived, known, analyzed, and changed.

Having been exposed to the thinking of Christopher Alexander through his book, Notes on the Synthesis of Form, and through interview (one was the address at OOPSLA 1996) and secondary sources over the web, including the CA Wiki page, over the last 10 years, I have tried to apply that thinking to other areas than building architecture. I have found the concepts amazingly useful in explaining the relationships between “things” in the world that can be “managed” and conceptually “understood” –as well as the “relationships” between things and their representations. Information systems presume the two “centers” cohere at some level and degree. Quality improvement processes require they cohere (there is a direct correlation between information/data quality and decision making quality–and between “corporate” decision making and product/service quality–and, in the aggregate, product/service quality and aspects of quality of life for customers).

It is true however that better and more things do not necessarily equate with “happiness.” (See Maslow’s Hierarchy of Needs) All of this productive process can be dehumanizing and life-detracting. But lifelessness is not a property of process. It is a function of the definition of the “good” we try to achieve–and the way we try to achieve the “good” we value.

The “good” does not emerge from the process we choose–it is in us, the process makers, before we make the process; it constrains how we manage the process; it may or may not be the result of the process, in fact. We may just “know” what is good at the grain of our everyday lives (where we touch/transform the centers in and around us). But what makes us good builders? Us. Me. Whatever is or is not there, examined or unexamined. There may not be a fissure between the objective and subjective, but that is because we ARE objective and subjective, both, always, at the same time, even when we think we are being analytical or emotional.

In my field, enterprise architecture, I have come to the conclusion that all organizational improvements run on the power of people. The classic EA Venn diagram shows People, Process, and Technology overlapping and implies they are co-equal. I think the elements are right, but they are not co-equal. The rise of Service Oriented Architecture (SOA) illustrates the primary importance of governance as the key to delivering SOA benefits to organization, partners and customers. Governance is a responsibility of people. In SOA people’s decisions are automated and center on Service Level expectations and measurements.

There is a real and deep connection between what is “out there” and what is “in here,” but the mechanism that defines the link (as CA describes) cannot be the reason for the link. It highly suggests a further deep interlock with unknown center(s) that bind all this together (and it cannot be versions of the “All that we touch,” which would be echoes at levels of local scale).

We know from knowledge theory that most information “managed” in an enterprise is tacit—carried around in people’s heads. Some of it is “codified”—explicitly recorded and managed. This ensures that, in adapting to a changing environment, people are always way ahead of “procedure.” They know what works and what doesn’t and they are creative and (usually) smart enough to make workarounds that don’t damage the enterprise mission (if they know and hopefully agree with it). People who get it wrong may pay a price. But many know “how to do it”—whatever is required and still stay between the lines.

The faster the environment changes the greater the disproportion between tacit and explicit. Gone are the days when knowledge work was a white collar version of stamping metal and keeping count. Knowledge workers are now problem solvers—and their tools must keep up. In such environments, EA obviously cannot be a bureaucratic, administrative task laden “process.”

So we have Agile EA and EA Lite. But do these approaches necessarily connect the business “user” with the structures and their relationships that form the “functioning enterprise” and express things like “secure information flow over emerging channels?” Does EA offer anything more than diagrams to help? Can EA actually help beyond pushing back office / front office sea changes?

For instance, there is a growing gap between work capabilities and home life capabilities—people communicate more effectively and in more advanced ways at home and around the world than they are enabled to do at work. Technology may be enabling (Moore’s Law) but it is market driven; the technology delivers the capability and people invent ways to use it—and people do. Why don’t we generally see this kind of innovation in both technology and process at work—as part of the “official” architecture? Can EA be more effective?

That is a fairly broad band of organizational territory extending from engineering functions in IT to process management functions in “the business.” The key is to build consensus 1) there is a problem that must be solved; 2) quick, short term fixes are not the solution, nor do they have to “boil the ocean” to see improvement; 3) that the pain is symptomatic of loss of adaptive capability that made them successful in the first place; 3) that adaptive, incremental approaches will restore that strength.

This middle band transmits the “will” of the business to the capabilities that execute business value and accommodates the business to the technical realities it can reasonably have. The Venn diagram that has people, process, and technology overlapping doesn’t quite state the primacy of people at the intersection. It is always people that regulate what happens, set/don’t set expectations, and make decisions about technical and process capability “fit and fitness” (as you say).

All forward progress/diversion is measured by people, for people. The EA Team must therefore be the “core” of a stewardship web that shepherds the way forward on a consistent path. This means it is not the EA “Program” or “Process” that guides the enterprise. And the latest technology vendor pitch can never be the “answer to all the dreams of the enterprise.” This “extended EA team” (and I would include business stewards) must be the author of reference models and architectures that define those “dreams” (aka To-Be/Target) and the means to get there (aka Roadmaps…). They are also the curators of the As-Is/Current (aka, “that which must not be screwed up in the process”)–because as you “get there,” that’s where you will be, and you want to be in a stable place!

This means architecture process should be “lite,” your artifacts should be collaborative results, and they should be readily understood by senior management. The extended team approach also means there should be constant awareness within the broader enterprise of its presence and intent.

In terms of gaps that I’d hope you address, the biggest I see relate to why companies adopt EA, how they adopt EA, how they struggle initially, and how EA is “sold” to the organization. These topics seem well suited to the SOA Governance writing style.

Best of luck with your (hopefully) new book!

Very interesting post regarding EA organization. Made me reflect about my company organization, trying to match your descriptions to it.
Thank you for sharing.