Architecture Fit and Fitness
In discussing how enterprise architecture supports merger, acquisition, partnership, and other evaluation opportunities with some attendees at the Troux 2011 conference this morning, I used two terms: fit and fitness.
Fit is how well things align between the two companies/products. for example, what do the capability maps look like? Did things get sliced up in a similar manner, or are they completely different? How does each company map their technology into the capability map? if the capability map is similar and the mapping of technology to capabilities is similar, then this is probably a good fit.
Fitness is the state of the things being integrated or merged. You can have a great fit, but if it is built on outdated technology, or has a poor architecture, the fitness is poor, and thus there is more risk in pursuing the activity.
What do you think?
2 Responses to “Architecture Fit and Fitness”
Leave a Reply
I would like to explore another angle on “fitness”—between IT and the business. In the EA trilogy, people, process, and technology, many dysfunctional attempts at EA start with a bias to process or technology—or some balance between the three. I think the bias is already built-in to the organization. We have always heard the “culture” is the hardest to change. I would suggest there’s a clue there that reveals the true nature of the enterprise: everything is finally mediated by people; it—the enterprise—really is, in fact, mainly about people, individually and in the aggregate. We may laugh at the “inventiveness” of people in “breaking the system” or getting around its “rules.” And we try really hard to make systems resilient and adaptable, customizable. Technology and process are the servants of people.
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?
I would like to comment more on the centrality of people in enterprise architecture.
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).