Facilitator: Paul Clements, SEI
Panel: Exploring Boundaries Among Enterprise, Systems, and Software Architecture
Wednesday, May 6, 2009, 1:00 pm
Panel explored the boundaries between genres of architectures. What do genres have in common, are there commonalities we can leverage, and what are the differences between the genres. Each panelist gave brief remarks, which were followed by questions from the audience and discussion among the panelists.
Zachman: This is a language problem. We have a lot of words we use, but not enough semantic clarity. For example, “enterprise architecture” could mean a lot of things. Without a framework or ontology, use of the word “enterprise” isn’t definitive and can be interpreted in many different ways.
Similarly with software and systems architecture, without a crisp way to allocate responsibilities and roles, we have difficulty communicating with each other. Need a way to objectively assign responsibility and allocate responsibilities.
Wirfs-Brock: Thinking about responsibilities and interactions between them. How to communicate between these models. For one client, I taught a class to mixed enterprise and application architects. Enterprise architects want to make sure governance models are relevant to application architects. But lining up their principles and values is challenging. We were able to make linkages between enterprise and application perspectives. They operate on different timescales. As a designer in software architecture, I feel comfortable going to people who model business processes, but my colleagues don’t. They don’t see it as real work. They see enterprise guys as looking out too much into the future. Need collaborative projects. Both sides need to get rewarded for this kind of collaboration.
Case: If you’re not doing architecture at many levels, it’s not going to work. John talked about architecture. Mark talks about architecting. We talk about the architect, who has to think at a lot of different levels. This is a framework for the architect—different from what John portrayed. This framework portrays a continuum of enterprise, systems, products, components. Standards are relevant at different levels of the hierarchy.
- Products (SW, HW)
How to deal with standards at different levels? We can talk about attributes and boundaries: at enterprise level, you’re talking about objectives, whereas at product level, you’re talking about implementation. Scope of architecture is broader at the enterprise level, and hence hard to bound. But at implementation level, if scope isn’t narrowed, I don’t know what to build.Tools are a cottage industry for architecture. I have to span lots of tools and standards. Use of tools changes based on underlying point of view.
Q: What should an architect do with these tools, because they don’t play together?
A: The question is, Who’s the audience for the tool? I have to pick the tool for the audience I’m talking to. Primitives underlie what an architect has to do.
Maier: Genres. Genre of objects: What do we architect? Alternative is a genre of role: buyer, owner, builder, user. The notion of genre is broader. As a system architect, I’m interested in building well-scoped collections of HW and SW, acting as buyer’s agent, not a builder’s agent. Define mission, someone else builds system in response to that. Linkage to strategy – architecture as the technical embodiment of strategy. “Architecture is decisions, not documents.” It reflects basic decisions about the fundamental structure of the thing, regardless of documentation.
Relationship to other genres: systems architecting exists in the context of a human enterprise. We derive architecture out from the basic direction of strategy. Bad and unfit strategy leads to bad and unfit systems. Buyer/user architect vs. builder architect: it matters which side you sit on.
In general, we pay too much attention to documentation and not enough to decisions. Poor documentation leads to many ills, but not necessarily bad decisions.
Some systems have emerged without documentation or architecting, e.g., the dabbawala system.
To evaluate fitness for purpose, we have to understand purpose. Too much focus on documentation leads to three-ring-binder architecture, without much decision quality. Better to focus on who makes decisions and how.
Hierarchy models = systems engineering catechism. It’s both true and false. Abandon notion of strict hierarchies. Hierarchy isn’t only way to look at a system. Think about it as a mission thread. What must occur to solve particular problem?
Zachman: Have to deal with things one variable at a time. I don’t like hierarchies. It’s a good implementation model, but not a framework. The world isn’t a hierarchy. Not good for engineering or normalizing things. OK for implementation only.
Q: Architecture is a communication problem. These levels have different cultures. Tools have semantic representations and assumptions built in.
Zachman: Tools respond to their view of the marketplace. The marketplace drives the tool community at short end of spectrum. They help us do implementation. Architecture work is engineering, not manufacturing. A lot of problems today are a result of a lack of architecture. We need engineering. There’s been a dearth of this.
Wirfs-Brock: We learn from implementation. Building architects did things from experience. Challenge is that we need to work at multiple levels at same time. Toolmakers need to make different representations of same concept for different purposes. The focus on execution and implementation as a designer of systems is constraining. I have to think down too early. There are multiple purposes for representation.
Maier: Cynical about grand unified processing tools. Rather have rich set of tools and make things up as we go along. One grand, glorious tool is not a likely solution.
Wirfs-Brock: We need diversity of tools.
Case: Architect must address multiple stakeholders and consumers.
Maier: The most useful tools are program-specific.
Wirfs-Brock: Why not just do things the way we do them now?
Case: We’re translating a lot between tools. Have to keep architecture books twice. Problem is that it doubles effort with no appreciable value for that effort.
Maier: Constraints or opportunities from software may influence the system. Being able to carry constraints and opportunities doesn’t depend on tool A or tool B. Need understanding of overall quality attributes of the system.