For enterprise architects, alignment to a strategy is often a core principle. They are well known for building governance mechanisms that trace all programs back to a strategy. But does that get in the way of self-organization? The wave of corporate implementation of mobile strategies is once again raising the question: How closely should we adhere to the principle of strategic alignment? (more…)
So, full disclosure, I care about Wikipedia. Call me dumb, I know. Wikipedia has been described, alternatively, as the best platform ever invented for fostering useless arguments among ignorant people /and/ the most successful encyclopedia effort of all time. The truth, as always, lies between these extremes.
Well, I’m part of a small team that is working to clean up the Wikipedia pages dealing with Enterprise Architecture. One thing that we noted recently is the fact that there are two pages, similar, both rather poor, that cover essentially the same topic.
We all know that Google lost a landmark legal case recently. As of now, a citizen of Europe has the “right to be forgotten” on the Internet. As of now, a citizen of Europe can ask Google to “forget” them, so that a search of their identity will not return embarrassing information from the past. This allows a person to live past a mistake. Your college indiscretion, and that time you were fired for photocopying your butt, or the time you got drunk and drove your car into a swamp and had to be rescued… all of that can “go away.”
However, this becomes much more difficult when we consider the emerging Internet of Things (IoT). In the Internet of Things, the “stuff” that you own can generate streams of data that do not remain within your control. That data is called “Information Property.” It is the information that YOU generate, in the things that you do. I believe that if YOU create a bit of information property, you should own it.
That information property, thousands of tiny bits of data about you or your activities, will wander out of your house, or your car, or your phone, to companies and governments running cloud-based data centers. That swarm of data surrounds you, and be used to profile you, track you, predict your actions, influence your choices, and limit your abilities to get “outside” the system. Most folks will not have any problem with this cloud of data. At least not at first.
Where we will first feel the pain of this cloud of data: when you want to be forgotten.
A parallel that does work
We have been dealing with “data about you” for a while. When you apply for a loan or a credit card, the information you submit becomes the property of your creditor, and they share that data with credit reporting agencies, along with your payment history, employment history, residential history, status of property ownership, and basically any other factor that finance companies feel would influence your likelihood to pay your debts. The US Federal Government has placed some controls on this data, but not many. Europe has placed entirely different controls. You have no right to be forgotten, but you do have the right to limit their memory to a decade. That allows you to “get past” a mistake or series of mistakes. But you are always “known.” However, a mistake can be forgotten.
This is a model we can use. Here is data, about you, outside your control, that get’s “forgotten” on a regular basis as it gets old. There is a possibility in the credit reporting world for being “forgotten” because the data is tied to you, personally. It is ALL personal data.
This is not (yet) true in the Internet of Things. If your car sends data to a smart roadway system, there is a great deal of information about where you go, and when, but under most circumstances, your identity is not tied to that data. It’s the identity of the CAR that is sent, but not the identity of the driver or passenger. That can be seen as an advantage, because it is tough to link that data to you, but it is possible, and therefore it will occur. You will be found. And when it does occur, you no longer have any easy mechanism to PROVE that the data from your car relates to you. This means that if any government creates a policy to allow you to be forgotten, the car data will not go away. You can’t CLAIM that data because it is not directly linked to you. You don’t own it.
Think this is a minor problem? After all, your city doesn’t have a smart roadway yet, and your car doesn’t send data, so this problem is a long way off, right? Wrong. If we don’t think of this now, privacy will be sacrificed, possibly for decades.
The environment of regulations sets the platform by which companies create their business models. If we create a world where you cannot claim your data, and you cannot manage your data, other people will start claiming your data, and making money. Once that happens, new regulations amount to government “taking money” from a company. The typical government response is to “grandfather” existing practices (or to protect them outright). No chance to change beyond a snail’s pace at that time.
I propose a simple mechanism. Every time you purchase a device on the IoT, you insert an ID into the device. This ID is a globally unique ID (my tech friends call this a GUID) which is essentially a very large random number. You can pick up as many as you want over your lifetime, but I’d suggest getting a new one every month. A simple app can create the GUID and manage them. Every item you purchase during that month gets the ID for that month.
Every bit of data (or Information property) sent by the device to the swarm of companies that will collect and work with this data will get your GUID.
Note that your GUID allows those companies to link your data across devices (your phone, your car, your refrigerator, your ATM card, your medical record, etc). Is this allowed? Perhaps one government or another will say “no” but that control will be easily worked around, so let’s assume that you cannot control this. The thing I want to point out is that this kind of linkage is POSSIBLE now, it’s just more difficult. But difficulty is being overcome at a huge rate with the number of computing devices growing geometrically. Let’s assume that folks can do this NOW and that you will NEVER be able to control it.
Therefore inserting an ID is not giving up control. You don’t have it now.
But it is possible, with the ID, to TAKE control. You will be able to submit a request to a regulated data management company (a category that doesn’t yet exist, but it is possible), then those systems can identify all the data records with your ID, and delete them. Only if you can claim your data can you delete it. By inserting a GUID into your Internet-of-things, you have gained a right… the right to claim your data, and therefore delete it.
It will no longer be a choice of sending a single message to a single search firm like Google. The request to delete will have to go to a broker that will distribute the request, over time, to a swarm of data management companies, to remove data tagged with these IDs.
Now, before anyone complains that a company, once they have data, will never let it go, I would submit that is nonsense. 90% of the value of information comes from samples of that data of less than 2% of the population. In fact, the vast majority of data will be useless, and plenty of companies will be looking for excuses to toss data into the virtual trash bin. If a customer asks to delete data, it costs a micro-cent to do it, but that data is probably clogging things up anyway.
Getting a company to spend the money will probably require regulations from large players like the EU, the USA, China, Japan, Brazil, and India.
The time to act is now
Now is the time to ask for these regulations, as the Internet of Things is just getting started. Companies that understand the ability to create and manage these IDs, and respond to the request to delete information, will have a leg up on their competition. Customers will trust these companies more, and the data will be more accurate for consumers of these data services.
You cannot delete “information property” until you can claim it. The ID is the claim.
As an Enterprise Architect, I’m first and foremost a problem solver. I don’t like to ignore problems. Yet, it appears that EA as a field has a problem and I’m finding it tough to ignore it. What is the problem? If you judge by the 1500+messages that have flooded the Enterprise Architecture Network on LinkedIn, Enterprise Architects cannot agree.
How did I come to that impression? Let’s look at the measures. Across a handful of questions over the course of the past few months, there have been literally hundreds of responses. Judging by the responses, we seem to have, as a group. different opinions about every facet of our profession. We appear to disagree about mission statements, value propositions, metamodels, methodology, inputs, outputs, and the necessary levels of job experience needed to perform.
Certainly the impression is reasonable, but is it a reality.
Yes and No.
There are a handful of “schools of thought” that emerge if you read and discuss. The number of people in each school of thought varies, but there are some clear distinctions between them. The biggest disagreements come from folks who are using the same words, but come from these different schools of thought.
The following list is in alphabetical order. Note that ALL of these folks have presented themselves as Enterprise Architects.
- Alignment Architects – these folks are focused on interpreting strategy, making it actionable, and using it to scope and define business change initiatives. Also referred to as Business Architects.
- Application Architects – these folks are focused on implementing successful “enterprise applications” or “enterprise systems.” Also referred to as Enterprise IT Architects (EITA)
- Information Architects – these folks are focused on managing information assets at the enterprise level in a consistent way
- Process Architects – these folks are focused on improving business processes or reorienting business processes to place the customer first.
- Strategy Architects – these folks are focused on helping business leaders create new strategies, open new markets, develop new products, etc..
Just to make things interesting, the Zachman framework (ZF) is used by a subset of “alignment” architects as well as a subset of “application” architects. So when you are discussing ZF, you aren’t even sure which perspective they are coming from. It is just as easy to get two “alignment architects to disagree about the value of ZF as anything else.
If you sort out the responses into groups on the basis of these different schools of thought, there is remarkable consistency among the answers. That’s right: consistency. People are saying similar things… sometimes even the same things… about the value, methods, and concepts of Enterprise Architecture.
Perhaps we need to split up the field into specialties, just as physicians have specialties, with some base training and a focus on a particular branch of medicine. After all, an oncologist makes a reasonable diagnosis when you have a cold, as would an Emergency Room doctor, but in the event of a car accident, I’d take the ER doc any day, and in the event of cancer, I’m making a beeline to the oncologist.
If we understand enough about an enterprise, and the problems that they want to solve, we can focus on a single specialty (and/or bring in the right specialist).
Solve these problems
With these architects
|We need new products. We need to open up to new markets. New opportunities have arisen. New threats are recognized. New competitive pressures are being felt.||
|We need to be more agile. We need to organize our business to deliver to our stated mission. We need to get our strategies to be realized more quickly. We need to cut waste. We need to focus on what matters. We need to implement new regulations. We need to respond quickly to corporate mandates.||
|We need to implement more scalable technical solutions. We need to integrate and/or replace complex areas of our line-of-business applications with packaged solutions. We need to add process flexibility into our systems. We need to consolidate business rules.||
|We need to make our processes more efficient and effective. We need to reduce friction between business groups. We need to minimize the cost of a business process, and remove waste. We need to refocus our processes on customer requirements and customer experience.||
|We need to create a single version of the truth. We need to reduce the amount of processing needed at each step of an information-based process. We need to reduce the difficulty in producing consistent reporting. We need to manage large amounts of information. We need to improve the ability of business units to communicate through consistent information.||
Perhaps if we begin to see that these folks are EACH needed, at different times, to solve different problems, we can spend much more time agreeing with one another.
One thing that often occurs when a team sets out to create an EA tool is that they create a metamodel that will be supported within the tool. As I pointed out in my last post, I would like to openly challenge tool makers to allow multiple simultaneous metamodels to exist, so that organizations can answer questions from multiple focused perspectives. In my opinion, this challenge will be quite difficult to realize.
I’ve been looking at some of the public documentation for various EA tools in order to see the metamodels that they support. This provides some insight into the level of difficulty of this challenge. Along the way, I’m also becoming reacquainted with some things that I’ve seen before (like a long discussion of the Troux metamodel that I got from an EA conference a few years ago, and the detailed understanding of the alfabet metamodel that I have first-hand experience with, as well as some exposure to the Aris metamodel from IDS SHEER).
I also ran across an open source metamodel that is part of the open source Essential project – a project to create an open source EA tool. (Personally, I think that open source EA tools are a good idea, but I think the business model that will ultimately win out is a cloud-based model that allows rapid deployment of an instance of an EA tool. Open source may not be the best way to deliver that business… but that’s a future post.)
The thing that I’d like to call attention to is the detailed open source metamodel that has been produced by the Essential team. Why is it interesting? Perhaps because the metamodel is open source but not community developed! In other words, I’ve seen no public discussion of this model and I cannot see any relationship between this model and those that have been discussed in public. Why would I adopt an EA tool that allows one model at a time, yet is based on a model that I’ve had no insight into how it was made or what problems it was designed to solve? Seems fairly backwards to me.
That said, the team that developed this model has done some very good work, and I recommend it to others for understanding and engagement.
My biggest concern, before I take the time to really jump in, is that the model seems to have been created in PowerPoint. That makes for some very difficult model analysis, which may mean that there are hidden defects in the model that are difficult to detect. That doesn’t mean that defects exist… just that I’ve not found that PPT is a good environment for generating metamodels due to the difficulty of debugging the model. [Correction: the model is produced in an OWL tool. The metamodel visualizations on their web site are probably just that: visualizations for the sake of consumption — NM, corrected 1-4-2011]
Note that clicking on each of the images below will take you to the actual page on the Essential web site where the model originates. No point in duplicating that data on my blog.
|Essential – Business Metamodel Elements||Essential – Application Metamodel Elements|
|Essential – Information Metamodel Elements||Essential – Technology Metamodel Elements|
One thing that I’ve come to appreciate is both the importance, and impermanence, of the Enterprise Architecture metamodel.
If that last sentence didn’t piss you off, you weren’t listening.
I’ve found two common groups of Enterprise Architects:
- Folks who do not understand, or care, about EA metamodels. Starting with Zachman aficionados, and working up to some practitioners of Balanced Scorecards, Business Process Management, and Business Strategy development (all fields that benefit from, and are necessary to, metamodels, but which were developed entirely without that concept). To the credit of many folks who have come up from these fields, they have seen the value of metamodels along the way and moved to the second group. Others, unfortunately, have not been able to see the holistic value of understanding knowledge using a connected model of well-defined concepts, and remain in the camp of “metamodel doubters.”
- Folks who believe that there should be a solid, unchanging, metamodel, and that all business and technical metadata should fit within it. The ranks of this group are growing rapidly, as TOGAF has adopted the concept of metamodels and as groups focused on Business Architecture have brought out research materials and books dedicated to specific metamodels. Readers of this blog will note that I produced a metamodel of sorts with the EBMM (Enterprise Business Motivation Model) nearly two years ago now, with an update to come soon.
Unfortunately, there are flaws with the thinking of both groups, and I’d like to propose a third way…
I’d like to propose that metamodels should be created as part of the “view", and not part of the “model” itself: That data will exist independently of the metamodel, in a manner that can be formed into a metamodel that is custom-suited to meet a particular need, at the time of that need.
Kind of hard to imagine, isn’t it? After all, as Information Scientists, we think in terms of the data structures… how data will be created, stored, manipulated, and consumed. And ALL databases have a data model. (the relationship between tables, fields, keys, indices, triggers, and constraints, as concepts, is an underlying RDBMS model). How, exactly, can we store data in a database without first creating a single model that describes the type of data that we intend to store, how it will be stored, and how it will be related?
Yet, we’ve seen the field of “unstructured data” blossom in the past decade with the emergence of search engines like Google and Bing. These engines have brought ever-increasing sophistication to the notion of “answering human questions” from data that is not, fundamentally, structured into an information model. That said, the most useful data in unstructured systems is still classifiable into complex types, and that classification allows the usefulness of that data to come through.
For example, if I go to Google and search on a local department store, I could type “Kohls in Covington WA”. I will get the results below. Note that if I go onto Bing and issue the same search, I will get nearly identical results. In both cases, model is applied. The word “Kohl’s” is taken to mean “a department store” and from that, we can add attributes. After all, department stores have phone numbers, addresses, can appear on a map, can have items on sale, and, almost as an afterthought, can link to a web site.
The search results illustrate far more than just links to web sites. The search engines are applying a classification to the otherwise unstructured information. To add value, the question is understood, and results are produced, based on classification. This “result” is not just a web site. It is not just “random unstructured data.” And the results are more useful as a result of this understanding.
Imagine that we have a search engine that works for business and information systems structural data instead of web sites. We can “know” a great deal of information about business motivation, strategy, competition, business goals, initiatives, projects, business processes, IT systems, information stores, software instances, etc, all the way down to servers, network infrastructure, and telephone handsets. But can we “apply the appropriate metamodel” to the data at the time when it is needed?
In other words, can we answer questions like these?
- What systems need to be modified in order to improve competitiveness as expressed through the business goals of the Retail unit?
- What is the accumulated Return on Investment of the projects that have completed in IT in the past two years?
- What gaps exist in the initiatives chartered to create a strategic response to the competitive threat posed by the Fabrikam corporation’s new product line?
Can we do it without pre-specifying a metamodel?
Folks in the second camp above will ask an obvious question here: why not catalog data according to a single super-dee-duper, one-size-fits-all metamodel? After all, once you have the right metamodel, every one of these questions can be understood and answered.
Let’s parse that idea a little… What makes a metamodel “right?” I would venture that a metamodel is not ??
?right” or “wrong.” It is simply “useful” for the purpose that it is being used for… or not. For example, sometimes I care about the distinction between a business process and a business capability. Other times, I do not. If my metamodel is static, I must always collect business data according to a single unified taxonomy, or I must always have two different taxonomies. But the world is not so simple. Sometimes, I need one. Sometimes, I need two. The metamodel is dependent upon the question I’m asking and the problem I need to solve.
In other words, the metamodel itself is a dependent variable. Only the raw data, the business stakeholders, and the business concerns themselves, are independent. All the rest is self-organizing and, here’s the problem, changes depending on the situation. The structure, relationships, and important attributes of any one set of elements is particular to the problem that the stakeholder is solving.
So, I will re-ask my question: can we collect information in a manner, and understand it in a mechanism, that allows us to apply different metamodels to the data depending on the need of the stakeholders?
I think we can. I think we must.
Some methodologies of software architecture, including EWITA, attempt to describe architectural processes in a manner that is quite separate from the development of software. Is that valid?
To whit, the first step in the EWITA process is described as “architectural requirements.” Yet, there doesn’t seem to be any definition, on that site, about what criteria we’d use to decide if a requirement is architectural or not. So if my job is to collect architectural requirements (hmmm…), then I have to ask, “what is an architectural requirement, and how is it different from some other kind of requirement?”
Consider this analogy
A few years ago, when I was considering making an addition to my home, we called an independent architect to come over and discuss details. We talked about the functionality of the rooms, and where they would be attached to the house, and what changes we’d need to make to the rest of the house. All of these requirements were shared with the architect, and he was planning to consider them all when creating a solution.
So are requirements architectural if the client tells them to the architect? I don’t think that is a useful definition.
Are some requirements more inherently architectural than others? Good question.
Some requirements came in the form of building codes. Were those architectural? Surely, they affect the architecture of the building, but so do requirements about function, size, and even the ease by which we would decorate a room.
In software, the same problem occurs. Business customers describe their use cases. Sometimes we talk about using data from other systems. Other times, we talk about speed and performance. Mostly we talk about functionality. What the application will do, and how it will make their lives better.
I don’t differentiate requirements as “architectural” vs. something else. It is not a distinction that I find useful. My question, fair reader, is to you: do you have a practice of attributing your software requirements with a note that says “this one is architectural?” If so, what logic do you use to flip that attribute to “true?”
I’m just not seeing it.
As I mentioned in my last post, we have produced an interesting conceptual model of IT as a business, from Business Motivation all the way through to Operations. For those of you who know I’m a SOA promoter: yes, I can represent a composite application in the repository.
More importantly, I can represent the reasons that a system exists, the metrics that demonstrate it’s value, the business rules that must be enforced, the business processes that take place, the people and organization hierarchy of the business, the programs and projects that drive change, the systems that deliver processing, security, and infrastructure services, and the operations that keep the lights on.
Microsoft IT is a big place (and apparently getting a little smaller, alas). So it is not possible for one team to “own” a model of this breadth without aligning with other sizable groups or divisions. There is no way to represent “one view of the truth” without creating a sense of shared ownership.
On the other hand, the motivations of each team can be different, and their perspectives on the model can be different as well. When creating a shared model, compromises must be made in order to get to a solution that actually works: rational, minimal, consistent, and aligned to the business.
With shared ownership, each compromise has to be carefully documented and signed off, because without that careful documentation, and the organizational will-power to refer to it, every compromise will be visited, and revisited, over and over ad nauseum. The noisy person and the politically well connected person will “earn” compromises in the model that challenge it’s quality and reduce its effectiveness.
On the other hand, as organizations change and adopt new ideas and well-organized principles, the model must change as well. We saw SOA add a different understanding of software applications and shared resources. We saw ITIL and MOF add a different approach to managing IT operations as services. Every year, something must change, even if it is just a little bit. Federated ownership is an excellent way to insure that those changes can be captured and incorporated.
But is federated ownership the only way? Of that, I’m not certain. If I look to the legal system, there is the body of law that has emerged through legislation, case law, and regulation that makes for a complex but workable system of rules and adjudications. There is no “owner” for all laws dealing with small businesses, for example.
In addition, if ownership is federated, what does that really mean? How does the central model stay consistent and useful when large subsections can change independently?
We have tried to create a central model that is minimal, that has only core objects and maintains only core relationships, so we can be immune from some obvious changes. On the other hand, this is an imperfect science. There is no way to be insulated from change.
Still mulling ownership structures. If anyone has any comments or advice, please share.
An esteemed associate of mine asked me recently if I believe that a conceptual information model, created and delivered independently from a process model, can be considered useful when attempting to improve a business. In other words, if you have an conceptual information model, can you use it directly, or do you need to produce a process model as well?
The answer, as is typical of EA answers, is buried in the question. If the goal is to improve a business measurable (like customer satisfaction, or average dollars per order, or customer acquisition cost), then the information model is not useful by itself. A process model that illustrates how the information is generated and managed must also exist.
So we will often need to develop both a conceptual model of a business and a process model for the business… but which comes first? Must they be done in parallel? Or should an architect create one before the other?
Personally, I know of cases where a process model existed long before a conceptual model did, and vice versa, so clearly the efforts are not contingent upon the other. In fact, in the situation I am in right now, the business has defined a rich process model that has grown out of date. I have separately developed a conceptual information model that includes concepts considered important by the stakeholders.
Now comes an interesting question: how do we take an updated conceptual information model and use it to improve an existing (but dated) process model?
I have my ideas, but I’m wondering if you, gentle reader, have specific ideas to share as well? I’ll outline my thinking, but I invite a discussion: is there a better way?
Situation: a project team finds that they have a conceptual information model, and/or business vocabulary, that is not in sync with the processes that the business says they want to standardize upon. How do we use one to improve the other?
- Step 1: insure the conceptual model reflects the complete breadth of the process model. This requires going through the process model and identifying all elements referenced, and insuring that they are correctly represented in the information model. Capturing nouns, verbs, and relationships is key to this step, as are the negotiation skills needed to get everyone to agree on the resulting diagram.
- Step 2: identify entities on the information model that are key entities. Indicators of key entity: (a) many different stakeholders define the entity as important to their work, (b) the entity is necessary to model the primary relationship between two other key entities, or (c) the entity is part of a key business measure. An example of the third indicator: if the business scorecard includes a measure of “number of open incidents” then the term ‘incident’ is a key entity.
- Step 3: establish dependency relationships for key entities. It is common for one data entity to depend upon another. The ‘order’ entity depends upon the ‘product’ entity, for example (in most businesses, it is difficult to order a product that the business does not have in their catalog).
- Step 4: define a loose process model that describes each of the lifecycle events of the key entities on a timeline: when is the entity data created? When is it used? When is it updated? When is it archived? When is it deleted? Drill down on the steps to identify where specific information must enter the process in order to manage the information.
- Step 5: compare the newly generated “loose” process model to the out of date process model in existence. Use the new one as a guide to making incremental changes to the existing process model.
OK… that’s a swag. Does anyone have a reference to a well documented and sound methodology for taking a conceptual information model and using it to improve an existing, and potentially out of date, process model?
The (ISO Standard) RM-ODP model is a powerful and well reasoned mechanism for creating Architectural descriptions (“architectures”). Leveraging the IEEE-1471 taxonomy, and building out a visual style and standardized approach, there is tremendous value in learning and using this the RM-ODP (Reference Model for Open Distributed Processing), and I’m getting to the point of recommending it.
That said, there is a gap in one of the most fundamental areas of the RM-ODP model. RM-ODP specifies exactly five viewpoints. This term is defined by the authors of RM-ODP as:
A viewpoint (on a system) is an abstraction that yields a specification of the whole system related to a particular set of concerns.
In other words, if you want to communicate with Joe, and Joe cares about 19 things, you’d better cover those 19 things when discussing the system with Joe. He has 19 concerns, and we can group those concerns together into 3 viewpoints (for example), and provide a “visual language” (my phrase) that can be used to communicate those concerns.
The next sentence, from the RM-ODP Overview (ISO/IEC 10746-1), is the problem:
Five viewpoints have been chosen to be both simple and complete, covering all the domains of architectural design.
Simple? Not so fast. The views produced by RM-ODP are far from simple… but…
Complete? I disagree. Big disagreement.
For those readers who are unfamiliar with the RM-ODP, this model describes five viewpoints:
- the enterprise viewpoint, which is concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part;
- the information viewpoint, which is concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;
- the computational viewpoint, which is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution;
- the engineering viewpoint, which is concerned with the infrastructure required to support system distribution;
- the technology viewpoint, which is concerned with the choice of technology to support system distribution
(There are many things wrong with this list. I’m only describing one of them here. Another will be described in a later post).
One viewpoint that the RM-ODP forgot is the one that matters the most to Enterprise Architecture: Alignment. I propose that the RM-ODP be extended to include the Alignment viewpoint.
The alignment viewpoint is concerned with the strategic and measurable purpose for the existence of a process or business system, and the justification for changing the features, structure, and operational profile of a process or business system, at a particular time, and in a particular organizational and technical environment.
The key concepts here:
Process or Business System — This viewpoint is NOT limited to describing a technology or line-of-business application. The views may (and typically do) limit themselves to business and informational views that do not illustrate any specific “ODP” system at all.
Purpose — The notion that a system comes into existence for the sake of fulfilling a purpose. That purpose is described in terms of business capabilities, business processes, business policies, business quality metrics, and business information. These explicit concepts describe the environment in which a system adds value.
Justification — The notion that any change to a system has to be justified. Enterprise Architecture is the business function concerned with insuring that all justifications align to the business changes implied by business strategy. Insuring that justification is based on strategy is an activity frequently referred to as ‘alignment.’
Note that, in a mature organization, alignment must be demanded to justify a change in any system, not just a software system. Changing a system requires care to prevent negative consequences on routine business operations, whether it is a system of people behaving with common goals, or teams behaving in a process, or applications behaving in a sequenced activity.
Some examples of Architectural Views that fall into the Alignment viewpoint:
Business Capability View — An illustration of the business capabilities of a particular business unit (at any level of a business hierarchy where clear responsibilities and accountabilities exist). Concerns for a business capability view may include the importance to strategy, staff readiness, process uniformity, cost of IT maintenance, flexibility of IT change, uniformity of information, maturity of process measurement, and scorecard value of process performance.
Business Process View — An illustration of the business processes and process activities necessary to support one or more business capabilities. May be demonstrated at varying levels of granularity, with the highest level representing abstract business processes (like “Marketing”) down to task level processes (like “Deliver Marketing Brochure to Publishing Team”). Concerns may include role and responsibility clarity, efficiency, effectiveness, uniformity, delegation of authority, and service level management.
Enterprise Project Portfolio View — An illustration of the business change programs in place throughout the business and how they align to meet the strategic and operational needs of the business. Concerns for an Enterprise Project Portfolio View may include overlaps by feature area, relative budget estimates by category, interdependencies by time, and feature delivery by time.
Enterprise Application Portfolio View — An illustration of the operational systems and processes in place to run the business, and how well those systems are prepared to adapt to potential risks and strategically driven projects. Concerns for an Enterprise Application Portfolio view may include applications that are impacted by multiple projects in close temporal proximity, applications that share similar functionality but different data stores, applications that share data stores but remain inconsistent in their implementation of rules, and applications that with high risk metrics (risk of failure * impact of failure).
Enterprise Information Federation View — An illustration of the core informational elements of the enterprise (like “customer,” “product,” “market offer,” “shipment,” and “service request”). Concerns for this view include addressability (the ability to find a unique data entity, using a readily accessible identifier, anywhere in the enterprise), consistency (the ability to insure that information that is shared by many people has consistent use throughout those who use it), and federation (the ability to apply the control of key data elements to the level that is closest to the team that needs or uses it).
Enterprise Technology Portfolio View — An illustration of the supporting business capabilities required by the business, and the use of shared technology platforms to meet those capability requirements.
While I have not met anyone who had told me that these views should be in the “enterprise viewpoint” as described by RM-ODP, I’m prepared to defend the notion that the enterprise viewpoint does not, in fact, cover this space. (A different post, perhaps, if it is necessary).