Most who read the blog title will suppose that the obvious answer is: there isn’t one. Or, at most, the difference is found in the classical differences between data and information; such as those that are described within a typical DIKW hierarchy. Perhaps that’s correct. Perhaps not. To this author, the answer is only accurate in context. For example, are you a Business Intelligence Architect depicting the relationship between database tables (clearly data) and business entities (clearly information)? Or are you a UX professional designing a website page map using a content taxonomy (information) and then mapping topics to each page as search engine friendly metadata (data)? Or is the difference more generally related to how “technical” a task is: for example, is it data-work when you’re designing data warehouse dimensional models – typically the task of the data analyst, database administrator, or data architect? But, is it information-work when you’re designing online store product categories – typically the task of the information architect or information specialist? This distinction is not terribly important, I’ll admit, but it is interesting how the market seems to imply that data is more technical (databases, tables, services), but information is more functional (dashboards, reports, websites).
Does this distinction matter? Do keeping the roles of a data architect and information architect separate really serve a purpose? I tend to wonder why DAMA International and the Information Architecture Institute appear to be on such opposite ends of the back office analyst vs. user experience professional spectrum (very different people occupy these roles). Is there an eventual convergence or is there more to this distinction than would appear on the surface? I would welcome your thoughts.
IT architecture makes use of views to represent aspects of a system from a related set of topics. These topics are related in their shared interest to a unique set of consumers of the information exhibited in the view. For example, the architecture description of an eCommerce website will likely use wireframes to describe the user experience to UI developers. Likewise, a set of PhotoShop mock-ups are of interest to end users who would like to visualize the finished product. Also, an database ERD can be used to describe the website’s backend database table structure to DBAs. All three “views” into the eCommerce website are accurate and complete – in that they represent the full website, but they are perspective-based; given the unique needs of the consumers of the description UI, end product, and database structure.
To carry the example further, let’s imagine that the organization developing the eCommerce website, would like to build other websites of varying degrees of similarity to the eCommerce site. Each potential future website would certainly have a UI, end users curious of the website’s look-and-feel, and database elements that would need to go to the DBAs for review. This would lead to similar views produced for the same types of consumers as the first eCommerce site. In an attempt to increase efficiency, the organization decides to create templates for these views. Each view template could include standard notation, the questions that came from the consumers of the views for the first eCommerce site, as well as common attributes characteristic of a template; such as a title and description of the data in the view. This company could achieve greater consistency, increased efficiency, and an opportunity of quality improvement by refining the template over time and allowing each use of the template to produce a view to provide feedback to the next use.
In an attempt to standardize the production of architecture descriptions for software systems, the IEEE in 2000 released a recommended practice entitled “IEEE Recommended Practice for Architecture Description of Software-Intensive Systems.” For those that are familiar with IT architecture already will know that this is the extremely commonly referenced IEEE 1471, but if you are new to the domain, or are still unclear on the differences between views, viewpoints, and models, hopefully this short description will help.
Views
In IEEE 1741, views are defined as “a representation of a whole system from the perspective of a related set of concerns.” In the eCommerce example above, the three topical views – wireframe, mockup, and ERD diagram, fit this description. Each view attempts to present the whole system, or a subcomponent of a large system, from an interest-oriented purview. This is done so that whoever is interested in the information in the view can understand the system in the way most pertinent to them. In civil and industrial engineering, an example of this concept would be the use of floor plans to describe the structure of the home to a contractor, electrical schematic to describe the wiring plan to an electrician, and a 3d model to describe the end product to the customers. Each view on the physical structure represents the entire building from a specific perspective based on the concerns of the stakeholder.
Models
Models are simply parts of the overall view. For example, wireframes of 10 different screens exhibit the view – the wireframe of the eCommerce site – with 10 different models – one for each screen. In IEEE 1471, models are not given specific definition, but they are discussed in terms of their contribution to a view and their consistency with viewpoints.
Viewpoints
In IEEE 1741, viewpoints are defined as “a specification of the conventions for constructing and using a view.” It goes on to say that they are “a pattern or template from which to develop individual views by establishing the purposes and audience of a view and the techniques for its creation and analysis.” Returning to the eCommerce website example, the process of creating templates for views would lead to the creation of viewpoints. The viewpoint attempts to embody the concerns, or topics, that the consumers of a given view are interested in, and thereby provide the view-creator – that is the architect – the promise of addressing the concerns of the view-consumers – that is the system stakeholders.
Below is a clip of the IEEE 1471 concept model that addresses these three terms with respect to one another:
Over the last couple years, I have been working out the implications of having a new architecture practice in an organization previously without one. A key issue that continues to surface is how important relationships are to architecture. This is true particularly when previous architecture decisions require governance to enforce and inform downstream project decisions. Lately, there have been several cases where a customer of a project has desired to purchase a given product and due to the impact to the architecture of that product and the fact that it does not promote key principles, something in the project had to change. This has meant that either the nature of the project had to change – implementation to investigation, project scope had to change, or even that the project, as stated, had to be cancelled altogether. It is at this point, when relationships have played an important role, in terms of defining an approach to communicate project changes. Here are a few of the lessons that I’ve been learning about relationships when it comes to communicating project governance decisions.
DOs
- DO use good stakeholder management techniques to determine who will care about certain decisions and why? By correctly identifying these people, I have saved myself time in re-explaining and re-justifying the rationale for a particular decision.
- DO communicate early and often. Once you have identified the stakeholders and their motivations, make sure to communicate to them as early and as often as possible. I have found that perfectly sane people generally take a day or two to acclimate themselves to a change in direction, especially if it’s for reasons that they don’t completely understand. The earlier you can begin this process, the better.
- DO include your boss in the stakeholders list. It might seem obvious and probably will depend slightly on the relationship to your boss and level of delegated authority you have, but it’s generally always a good idea to have your boss agree that a particular principle is applicable or that your suggested changes to a project are correct. Otherwise, you might find yourself discussing things with people, simply to have to back pedal when your boss gets brought in. Or, worse, if he brings himself in. This one might be more clearly stated, DO acquire or verify the authority/validity of a decision before communicating it.
DON’Ts
- DON’T assume that just because someone has heard you that they agree with you. It’s easy to become so convinced that what you’re doing is correct that you don’t take time to examine body language or ask probing questions. Silence isn’t agreement. Not that you won’t have to still make the decision to change a project, but you might discover something about the user or project manager’s requirements or motivation you weren’t aware of that might influence a change.
- DON’T communicate the decision in terms of architectural benefits. Chances are the stakeholder won’t care about “architectural integrity” so don’t forget to use contextualization and empathy to consider this stakeholder’s chief motivations, vocabulary, and communications style. Make sure to approach them on their terms and in their terms.
- DON’T be afraid of conflict and debate. Conflict can definitely escalate to unhealthy or unhelpful levels of intensity, so managing conflict is important, but don’t avoid it. Many decisions are only internalized by both parties as they are processed through debate and rationalization. It might be necessary for things to become slightly heated before a change is viewed as valid or even understood. Don’t provoke an argument, but don’t smooth it over either. Conflict is like debt, you can defer it, but you can never avoid it.
These lists are not exhaustive, so I would be glad of comments to this post that share your examples. I have definitely been shocked at how important relationships are to good architecture decision and governance. Managing these relationships well, starts with the realization that people are more than a means to an end and that collective contribution toward decision making (“group think”), though painful, is more effective in the long run than simple “because I told you so” tactics. Externalizing assumptions and internalizing decisions – relationships help facilitate both of these.
Having relatively recently earned my PMP, I have spent considerable time learning and practicing the science of project management. One of the key topics within the discipline, especially when discussing the scope, is requirements. I have also finished a solid year of research on architecture, which culminated with a reading of the TOGAF v9 specification, and there is much said in architecture literature about capturing and managing requirements. As I am attempting to formally establish an architecture practice at Liberty, there have been several questions around whose responsibility it is to manage requirements? The project managers think, for good reason, that requirements management is their responsibility. But having read TOGAF, especially the ADM, I am convinced that architecture also plays an important role in identifying and managing requirements. I think, like so many things, the ownership depends on the practicing organization’s structure and discipline. Below are some of my musings on how requirements responsibilities are worked out in three types of organizations.
Organization 1: No Formalized Architecture
In this organization, there is no formal architecture practice. This means that there is not a department dedicated to architecture and planning within IT or the broader enterprise. It also means that while there might be individuals with the title “architect,” there has not been any structure linking their activities directly to project work. In this organization, those who manage change efforts have the title “project manager” or something similar, and are functionally responsible for requirements gathering. As project managers, PMI has outlined several tools and defined outputs of requirements management, and while I take some issue with the lack of clarity expressed through the PMBOK around this topic, these are definitely good starting points for any project manager.
Requirements Management from PMBOK
-
Tools
- Interviews
- Focus Groups
- Facilitated Workshops
- Group Creativity Techniques such as brainstorming, mind mapping, Delphi
- Group Decision Making Techniques
-
Outputs (Documents)
- Requirements documents
- Requirements Management Plan
- Requirements Traceability Matrix
Organization 2: No Formalized Project Management
This organization either does not have any project managers or has not formalized its project management practice around a repeatable discipline. Liberty University’s IT division has been transitioning out of this type of organization for the last few years. While we have had project managers for as long as I’ve been at LU, there has been a high degree of variability between the tools uses, processes followed, outputs produced, and ultimately quality of delivered project. For us this has meant that when the project manager wasn’t collecting good requirements, others have led the charge. Most often those people were the lead engineer or that engineer’s manager. The justification for this has typically been that in order for the engineer to produce a product or solution, he needed solid requirements. On projects without solid requirements from the project manager, they were stuck doing it themselves. While according to PMI, this isn’t ideal, I am not convinced that this is always a bad thing. As I have researched architecture, I have seen that there is often a person who bridges the gap between the contractor (project manager) and the customer. We weren’t calling that person an “architect” at Liberty, but in most mature organizations, it would appear there is almost always a back and forth between project manager, customer, and architect. I think that while we’ve made strides at maturing one role – the project manager – in that triumvirate, I think the maturing of architecture development would have had equal, if not greater impact on requirements gathering.
I think this for two reasons. First of all, in most cases the architect will have skills that the project manager does not have. For example, I have worked as a software engineer and developer long enough to recognize the value in rapid (or even paper) prototyping; that in doing so you provide a quick view into what the end product could be? The chief purpose of which is to assess, refine, and collect additional requirements. The project manager in most cases, unless they are moderately specialized, will not have the ability to produce these prototypes. I believe this would and should fall on the architect. Secondly, it is evident from TOGAF, that gathering and rationalizing requirements is a central aspect of their ADM. Therefore, I believe that in organizations where there is no formalized project management, leadership should invest in staffing and training both project managers and architects. And, in the instances where these organizations already have architecture as a formalized discipline, I would wonder if they are not also functioning as project managers? If this is the case, then having architects trained in formal project management might provide even more benefit than staffing a separate role.
TOGAF on Requirements
Organization 3: Both Architecture and Project Management
In this organization, there is at least an attempt to have a formalized discipline for both architecture and project management. Requirements gathering activities for projects in Organization 3 should be the duties of both the project manage as well as the architect. This implies that there is an architect assigned to every project. I believe this is a critical point – if an effort is sufficiently large or complex such that it merits a specific project manager, then I believe that it also merits a specific architect. This might mean that some efforts have a project manager who is able to perform the duties of an architect and it also might mean that some projects are managed by architects.
My Thoughts…My Conclusion
I recognize that this blog is less scholarly than others and that my opinion is relatively meaningless when it comes to experienced architects, but I definitely am keen to the idea that architects do architecture well and project managers do project management well and that both should be committed to the act of requirements gathering. If projects are to successfully meet customer expectations, then they must do so through solid requirements gathering and management. I close with this quote from The Atlantic Systems Guild, Inc. on Mastering the Requirements Process,
Requirements are the most misunderstood part of systems development, and yet the most crucial. Requirements must be correct if the rest of the development effort is to succeed.
I have had some recent discussions about tool that I produced which is meant to allow projects to be assessed based on their architectural reuse of a set of core building blocks (BB). The proposed value of this would be to allow architecture development within a project to demonstrate architecture building block (ABB) reuse through a BB-Requirements matrix, where each project requirement would be mapped to a standard set of core ABBs. The matrix would theoretically show that the more BB-Requirement intersection, the less risk of unnecessary and non-compliant components being introduced by that project’s proposed architecture. This tool has been sent out to a few people and interestingly, one of the first questions that has come back has been related to IT management. Essentially, the question was this:
What is the difference between a TOGAF building block and an ITIL CMDB Configuration Item?
Since we are in the process of implementing an ITIL-compliant ITSM system, people’s attention towards topics like CMDB and CIs are definitely heightened, but the more I consider the question, the more I am drawn into this topic: Truly, what is the difference? Or, are there any differences at all?
A Configuration Management Database (CMDB) according to ITIL v3 is:
A database used to store Configuration Records throughout their Lifecycle. The Configuration Management System maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and Relationships with other CIs.
A Configuration Item (CI) according to ITIL v3 is:
Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained through its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software buildings, people, and formal documentation such as Process documentation and SLAs.
A Building Block (BB) according to TOGAF v9:
Represents a (potentially reusable) component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. Building blocks can be defined at various levels of detail, depending on what stage of architecture development has been reached. For instance, at an early stage, a building block can simply consist of a name or an outline description. Later on, a building block may be decomposed into multiple supporting building blocks and may be accompanies by a full specification. Building blocks can relate to “architectures” or “solutions.”
Without claiming to be an expert in ITIL or TOGAF, I have attempted to outline similarities and differences that I believe exist at first glance. There are definitely several ways to look at the nature of the data and metadata which populate an ITIL CMDB or a TOGAF Meta Model-based Architecture Repository, but since I’m still learning to apply both knowledge areas, I’ll leave my assessment at only the surface level. Feel free to comment with additional thoughts or opposing views.
Similarities
- Components: CIs and BBs are both discrete components – hardware, software, locations, roles, services, etc. – each with a unique set of attributes.
- Relationships: Both are expressed not only in terms of their own attributes, but are most valuable when relationally modeled in respect to other components.
- Abstractions: Both make use of abstraction, composition, and decomposition to express “low level” components and their relationship to “high level” components.
- States: Some Configuration Management Systems (CMS) are able to manage transitional states between the current state and previous transitions or even proposed future states. This is similar in concept to the transitioning of a BB from a current to future state. Though, the implementation of this is dependent on the ITSM and CMS, CIs definitely support the idea of states.
Differences
-
Single vs. Multiple Perspectives
One of the biggest differences between a CI and a BB is the framework that manages them. Since ITIL is primarily a Service Management framework, CIs are typically represented in a service model. Because of this, I would imagine that almost never is there a CMDB dedicated to managing the relationships between organizational goals and a process, nor is data typically modeled in a CMDB at all. Therefore, I believe you could consider ITIL’s service models to be a single Service Management view of the broader set of views required to model EA. This means that only the CIs required to model this view are housed in the CMDB.
-
Operational vs. Strategic Functions
Since the CMBD typically only manages CIs related to service management, it is particularly helpful to those performing day-to-day service management activities. Consider a strategy map dashboard which shows strategic goals, their relationship to one another, and rolls up health information for each goal. This would be another operational view, supported by EA modeling which would not fit into a typical CMBD and therefore is not a candidate CI.
-
Service Management vs. Enterprise Architecture Context
In summary, I think the biggest difference between CIs and BBs are their context. The systems which attempt to support this context do not take into account other uses. While the CIs in a CMBD are relegated to only those required to model the service management view, this does not have to be the case. Nor is it true that there shouldn’t be some collaboration between CMDB and EA repository vendors to support a dual purpose system, where BBs are able to be made into CIs in support of the IT service management view.
A view is a tool used in enterprise and IT architecture, to display a particular perspective of a system, process, or change in a manner which communicates the most relevant, and therefore meaningful, information to a specific set of stakeholders. TOGAF says it like this,
A “view” is a representation of a whole system from the perspective of a related set of concerns.
As discussed in TOGAF v9, the formal definition for basic architectural concepts (ISO/IEC 42010:2007) shows views as the organizational tool of an architecture description. TOGAF bases its use of artifacts – catalogs, matrices, and diagrams – on this idea, stating that a variety of artifacts are necessary to communicate the architecture to the stakeholders who each have a unique viewpoint and therefore demand a view or a number of views.
While TOGAF does use views, I found the number of possible views to be incredible – 56 possible artifacts! Before reading TOGAF, I had seen views used in a less broad sense for software architecture in the 4+1 View Model of Software Architecture. In 4+1 there are 5 possible views – logical, development, process, physical (4) and use case (+1). In this model, the theory is that you start with the +1 (use case) view which helps capture what the user’s requirements are? Then you create the subsequent four views based on the needs of the architecture’s stakeholders. The stakeholder-tailored approach is found in TOGAF, 4+1, and all frameworks and methodologies that I have come across, so TOGAF’s 56 will never be the right answer for any question of “how many views to use?”
Since there are similarities between the possible views in TOGAF and the five in 4+1, I wanted to take a stab at aligning these two approaches. Below, I’ve taken each of the 4+1 views and listed the TOGAF view (diagrams only) that I thought best matched the 4+1 view. Hopefully, someone will find it interesting, helpful, or even worth commenting. I recognize others could debate which views go where, so please chime in with your thoughts.
Use Case
- Solution Concept
- Business Use-case
- Process Flow
- System Use-case
- Events
- Business Service/Information
Logical
- Class
- Class Hierarchy
Development
- Application & User Location
- Software Engineering
- Application Communication
Process
- Data Migration
- System Use-case
- Process / System Realization
- Processing
- Data Security
Physical
- Communications Engineering
- Platform Decomposition
- Network Computing Hardware
- Environments and Locations
Much has been published in the last five or so years about Enterprise Architecture. While Zachman and Spewek have been attempting to promote the idea for much longer, the recent frenzy around EA has been a great thing for maturing the profession and the promoting and expanding discipline of IT architecture beyond its technical realms. Many proponents have even carried this idea of “architecting the enterprise” into non-IT parts of the organization, claiming that EA is much more about strategic planning than specifically an IT process. I would agree with that. I also agree whole heartedly that EA is just as important, if not more so, to the organization’s strategic planners as to the IT program or project planners. Therefore to distinguish EA from other senses of the moniker and to partner with Zachman’s use of all capitalized letters for ENTERPRISE ARCHITECTURE, I have begun referring to this super-architecture; i.e. the process of architecting the enterprise as an independent system needing a planning process of its own; as Big EA. It’s in this sense that analysts at Gartner and Forrester to authors Bernard and Ross to Zachman to the writers of TOGAF, FEA, FSAM, etc. are referring to Enterprise Architecture. They are referring to Big EA.
There is, however, a less specific meaning to the distinction Enterprise Architecture. In organizations where there is little to no formal IT architecture process at all; where there is no formal architect, design, build progression; before Big EA can take place, there must be enterprise architecture or little ea. Little ea is the enterprise process for doing architecture, such that all people engaged in building are required to participate in a repeatable architecture process. Big EA can certainly happen before little ea, but without little ea, Big EA is forced to be focused on its own architecture alone and will have a difficult time consulting or reviewing or recommending or collaborating with other non-EA driven projects, whose specifications are non-existent. Organizationally, I am finding too, that outside the context of IT, there is generally little understanding of something as seemingly non-technical as architecture. That is until business folks sees it happening within the context of projects they directly requested. What I mean is that if we ever hope for Big EA to be a part of how the organization drives strategy, then it will need to be seen as a viable and relevant business activity on operational projects. Without little ea, the business does not experience architecture until it comes from the highest parts of the organization down. That is, of course, assuming that it would even be promoted downward by executives that probably don’t understand architecture’s presence in IT or business.
Unless you have support at the highest levels of the organization for an EA capability, in the Big EA sense, and if there isn’t architecture being employed in your IT ranks to systematize planning and execution, then my take is to start there. It will allow the organization to mature in concert with the collective frames of reference we all use to assess value and leverage tools. If EA is to be useful, then it must be practical and relevant.
A couple years ago, during the earlier days of my architecture research, I was often confused by three topics – frameworks, patterns, and methodologies. While I would not consider myself an expert on these topics, hopefully this article will suffice as a jump start for anyone whose understanding is still in need of some clarity.
Frameworks
Frameworks, as least as they relate to the computer sciences, are in essence a model. They are a representation of and typically a usable structure for implementation in a given scope. Usually embodying best practices or fundamental primitives based on best practices, frameworks can be used to follow a widely accepted behavior or produce a more predictable output. Frameworks are typically created to support long term behavior and thus support implementation techniques such as component reuse or foundational repositories from which reuse can occur. Frameworks can exist in any of the major architecture domains – business, data, application, technology – or in the case of FEAF or TOGAF act to organize entire supersets of behavior. Frameworks organize through interface or usage constraints defined by the model. Another example of a framework, are common software libraries, where they place organizational and structural constraints on the modules which leverage them.
Examples of architecture frameworks: TOGAF Content Framework, ITIL, and EA3 Cube
Patterns
Patterns found their way into IT via Christopher Alexander, a building architect, whose ideas were adapted to the world of software engineering by the Gang of Four in Design Patterns: Elements of Reusable Object-Oriented Software in 1995. Defined as “an idea that has been useful in one practical context and will probably be useful in others,” their concept was that if architecture and design in the physical world could extrude some valuable insight about shortcuts to good design, then software engineering could as well. This idea has largely not been adapted to systems architecture as is evidenced by this quote from TOGAF, “Patterns for system architecting are very much in their infancy.” It could be said that one of the reasons for this is that frameworks tend to act as a macro-pattern, and patterns themselves are often found in more local application, such as in specialized design patterns.
Examples of architecture patterns: Client-Proxy Server, Layered Architecture, and Pipe and Filter Architecture (TOGAF on TADG)
Methodologies
Methodologies, unlike frameworks, are not organizational in nature and are typically not found in architecture domains. Unlike patterns, they are not useful examples, though they may contain examples. Methodologies are typically a process and are always towards some particular and predictable end. Frameworks, as in the case of TOGAF, might contain methodologies (ADM) but they do not typically contain frameworks, though they may prescribe their use. Methodologies are about “what you do?” not “how you do it?” which is more of the case for frameworks and patterns.
Examples of methodologies: ADM, SDM, PRINCE2
As I’ve written this article, I have found (which is really the desire for this blog to begin with) that my understanding is less clear that I had hoped it was. I feel as though I have only done a small amount of justice to defining these terms, establishing them in respect to one another, and giving examples. Please comment with any additional thoughts or corrections. I’d love to hear your feedback.
Some of the earliest conversations I had in my career about planning through some form of structured specification process were around the topic of design. At the time, I would have asked a reciprocal question “what’s architecture got to do with it?” Now, having spent the last two years in architecture research and understanding a bit more of the domain of planning and governing system implementations, I’ll offer this post to summarize a few of the confusing points that I’ve found along the way.
- Design is not architecture. This paper from Eden and Kazman (2003) attempts to theoretically assert this position and equally, in support of my last post, that they are both different from implementation. The intension/locality thesis is helpful here, which states that “Architectural specifications are intensional and non-local; Design specifications are intensional but local; and Implementation specifications are both extensional and local.”
- The term “design” does not always mean design. Based on the idea that you’re either discretely doing design or architecture work, there have been some interesting conversations that I have been a part of over the last year or so, which take me back to my aforementioned roots. I am finding that those who have their history in software development are much like me in that, in the earliest planning activities, they most clearly identify with design not architecture. Often the phrase “high level design” is mentioned when discussing the planning activities for a software project. Based on Eden and Kazman, I would wonder if a high level design process, the output of which would probably be a document which contains this design for the entire software project, would constitute architecture due to its non-local influences. If you consider this paper from Kruchten, his approach to software architecture very much fits in line with what others would consider to be “high level design.” I tend to believe that for any given software system, a software architecture based on an appropriate framework (4+1 View, for example) will sufficiently cover any requirements of a high level design process, thereby reconstituting high level design as normative software architecture.
- Design must be informed by the architecture. In the event that my interpretation of Eden and Kazman and my application of the discipline of software architecture to high level design activities is inaccurate, then it is still worth noting that any design – be it high or any level – should be structured by a governing software architecture specification. One of the more recent instances of where this has been evident to me is in some high level design documentation I reviewed. It was apparent to me that without a governing architecture, the terms and levels of abstractions found in the design documentation were neither consistent nor all together helpful. Describing software systems should be a top-down activity where starting with the architecture is first applied to defining the domain of the software system itself. If there are to be concepts used in the design and implementation which are defining characteristics of the system, then they must be first set forth in the architecture. Only then should they be explicated in the design and then found to be implemented consistently in the construction. This might be obvious to some, but it is certainly not obvious to all.
- Design has implications in both UX and SE. User Experience (UX) has become a prominent area of interest in the software communities, especially so in the website construction domain. I will often reference Boxes and Arrows because of its influence on my understanding of this area of study. As I mentioned before, there are no doubt software and systems engineering implications on design. To again make reference to Eden and Kazman, “Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements” [quoted from D. E. Perry, A. L. Wolf (1992)]. Therefore is it is seen that design is clearly a part of the engineering practice. The disciplines of UX and Information Architecture (IA) have also claimed design terms and usages. Where the phrase “design patterns” in IT is traditionally heard in connection to Façade or Factory, it is now being used to talk about Clear Entry Points and Spotlight Transition for UX design patterns. Anyone who has encountered design in non-IT context or has read Norman’s The Design of Everyday Things, understands that design is everywhere, but the salient point here is that design in IT is less clear than we often think. I think there is work yet to be done to systematically connect UX and SE design work. They have much to learn from each other.
- Design is like architecture in that its use in SE tends to depart from other non-IT domains in terms of roles and responsibilities. For non-IT projects there are usually at least three distinct types of people involved in the respective architecture, design, and implementation activities. For example, a house is “designed” by an architect and then designed (in a more traditional sense) by the interior designer. Architects define spaces where design activities can consist. In the SE world, the same person is often performing both the architecture and design activities. It is not completely clear to me, largely because I don’t think the entire set of applications for the words architecture and design are completely consistent, how and where the duties of one discipline start and stop. What is clear to me is that often SEs are called on to architect, design, and implement systems all themselves. I wonder if as IT continues to mature as a discipline, there will be globally recognized analogous specializations forming around architecture vs. design? I think the increasing use of architecture frameworks and the UX specializations are certainly evidence of a shift.
If you find yourself on my blog, then I’d love to hear your thoughts on any or all of these points. Thanks for reading.
John Zachman has no doubt influenced many IT architects, since he began his public architecture work in the ’80s. I am definitely one of those architects. His thinking and passion around the discipline is definitely inspiring and his obvious obsession with precise language has personal resonance for me. I am definitely a stickler for terms. After all they are the foundation for thought and communication. Terms and their implied definition (their meaning) are the substance of some of the most profound ideas as well as the most catastrophic misunderstandings. This personal quest for clarification and an appreciation for Zachman lead me to this article he posted on the differences between architecture and implementation in 2007. I’ll not summarize here what the entire article says, since I would not want to do any injustice to his fervor, but this quote says it all:
NO!!! IMPLEMENTATIONS ARE NOT ENTERPRISE ARCHITECTURE!!! Implementations are the result of architecture… If any architecture has ever been done!
Anyone who happens to stumble on to my post should definitely read Zachman here, but I think I’ll try to apply his article to its local meaning. Here are the implications of Zachman’s article drawn out to apply to my own relatively new attempts at the practice of architecture:
- All abstractions step away from the same core – the implementation – to the same degree. This means, that it is the job of views (see perspectives below) to “abstract” away from the technology itself. Being a technologist, and x-developer, I have a tendency to think that the closer I get to the business the further away, or more abstract, I get from the implementation. I think Zachman would disagree with this. It would appear that presenting the specification to various stakeholders of a potential implementation is an abstraction away from the implementation for all parties, including the developers. This makes perfect sense if you consider that the business is indeed implementing the architecture to the same degree of instantiation as a developer would. This appears to also play into TOGAF’s view that the business itself should be architected by dedicating to it its own Business Architecture domain.
- Considering my lesson in abstractions above, Zachman also has something to say about the use of Perspectives. Perspectives, or views, can give the architect the ability to relate the details of the implementation to increasingly higher levels of a traditional organizational model. In his article, bottom-to-top, he lists technicians, engineers, architects, executive leaders, and strategists as the recipients of the perspectives represented by the architecture. This idea of perspectives doesn’t appear to be completely shared with other work using views, such as the 4+1 Views for software architecture, where every view does represent a different role, but not necessarily in a bottom-up organizational hierarchy. I wonder if Zachman would say that his framework is attempting to deliver on the ENTERPRISE Architecture value proposition, which identifies the need to perform architecture for the system of the enterprise itself? This would indeed make sense, and ultimately points to the importance of role definition and taxonomy, for any architect. Without defining the roles, it becomes impossible to decide what those roles need to see in order to understand the implications a given architecture has on their implementation-work.
- It was in this article that I first encountered the thinking, though it probably is exceptionally obvious to everyone else, that the product of Enterprise Architecture is like any other architecture discipline that bears its title before the term. Just like Product Architecture, Project Architecture, Solutions Architecture, Information Architecture, and Building or Structural Architecture are all describing both a process and a product, so Enterprise Architecture is more than just a process of rationalizing all of the architecture activities throughout the enterprise. It’s also concerned with the product of the ENTERPRISE itself. I’m sure I’ll write more about this, as I’ve read other works which help make that concept more accessible, but the idea that the enterprise itself is a system which is a product of the process of EA was deep and meaningful.
To summarize:
- All abstractions, in the context of Zachman at least, are equally distant from the implementation.
- Perspectives are only meaningful in the context of solid role definitions and relationships.
- Enterprise Architecture is just as much about the process of architecting the enterprise as it is the product of the enterprise itself.
metataxonolobotomy 