Enterprise Architecture has a role to play in both developing a vision of the future, and in providing governance and oversight to make sure that the organization can measure its progress towards that future.
The governance part is tricky. Architectural Governance is part of a larger fabric of governance that needs to exist throughout the organization, not just in IT but also in the business groups themselves. This means that governance has two masters. Governance has to align to business value, on one hand, and “measures of compliance” on the other.
For enterprise architecture, the business value lies on the proposition that systems designed with better architecture will be more flexible, maintainable, and reliable than systems that are not. Measures of compliance, on the other hand, can include things like “numbers of projects reviewed” or “evaluated quality of architecture is trending upward.”
In my opinion, governance is about motivating people to do the right thing. All compliance programs are really all about helping a person or team to do the right thing. There are may ways to that goal.
Of course, it’s a challenge, in any society or organization, to define what it means to “do the right thing.” I’ve noticed, as I conduct the architecture review program here in Microsoft IT, that there is a spectrum of governance. Different people in the organization tend to fall somewhere along this spectrum. Some folks want to “educate and encourage” good behavior, while others want to “monitor and inform” management about bad behavior.
The reason that I point out this obvious fact is that your Enterprise Architecture governance program will have many components. One component may surround innovation, and another may surround process improvement. In my organization, we have a governance process around architectural standards and review.
Each component will have an owner. The owner is the person who is accountable for insuring that a particular behavior (do the right thing) is happening. For architectural review in Microsoft IT, that is the Microsoft IT CTO Barry Briggs. He also happens to own the measurements for our architectural repository.
For each component of governance, it is important that you expose the governance owner to this spectrum and get agreement to the question: “Where on the spectrum do we want to be?” Even better: add the element of time to the conversation. “Where should we start?” and “Where should we end up?”
By getting your compliance owner to declare, specifically, where your compliance program needs to be on this spectrum, you are able to do many things:
- Everyone, including the compliance owner, knows and understands the posture that the compliance team needs to take. Other folks may want to interject their own opinion about where, in the spectrum, compliance should land. If the compliance program team members have a clear direction, then communication is clear, processes can be correctly designed, and expectations can be correctly set.
- The compliance owners’ direct manager (often an executive) can have some idea about where the compliance program is going and why it is going there. In some cases, this means that the executive can take responsibility for the level of risk they are accepting.
- Processes won’t get out of line with the intended behavior. I’ve seen examples, from our consulting engagements, where the business wants to encourage a particular behavior, and they asked for compliance processes, only to produce the opposite of the desired effect.
In one case, one of our partners was working with Microsoft on their SOA program. Their IT Leadership wanted to improve the use of shared services. They developed a shared service reuse program and a governance model to make sure that everyone used the services. The governance program was poorly rolled out and executed, and the program lost credibility.
As a result, whenever anyone asked about using those shared services, that person was derided and their idea discarded. In order to get past compliance, managers created a crafty way to “game the system” in reporting the results. While the compliance numbers looked good on paper, the actual use of shared services declined overall. The program that sought to increase the use of shared services caused it to decline instead.
Compliance is part of the game when you are trying to encourage good behavior in an organization. Making it work is not easy. The person responsible for insuring that compliance occurs has to have the right level of ownership and accountability. But just as importantly, they need to carefully consider where, on the spectrum of governance their program should be, now and in the future, in order to deliver on business value without encouraging different kinds of bad behavior.
One thing that any new Enterprise Architect realizes, on or around their first day of work, is that there are not very many other Enterprise Architects in their organization. It is easy to look around and discover that you are the one and only Enterprise Architect, or part of a very small team. That doesn’t do much to relieve the pressure, though. An Enterprise Architect is expected to provide a lot of value, without a lot of direct resources.
For this reason, a key concern of Enterprise Architecture is “how can I be accountable, and deliver value, without a lot of direct reports?”
This question is easy to answer: Collaborate. It’s a lot easier to say than do.
It is not enough for an EA to “want” to collaborate, or even to be “open” to collaboration. Other roles can make that claim. The EA has no choice but to “drive” collaboration: to make collaboration happen in situations where your stakeholders may actually be incented to ignore you, disregard you, or outright oppose your very existence.
And there’s the rub. How does an EA create an environment of collaboration, and mutual interdependency, without wielding a large club? There are many answers to this question, but the one I want to touch on, right now, is “the appeal to common values.”
Using the Appeal to Common Values
At the end of the day, it is impossible to force another person to do the right thing, especially if you don’t have the right to cause bodily harm :-). You can appeal to their manager, but that only works when their manager agrees with you. You can try to use logic, to convince them that your ideas are sound, but that doesn’t mean that they will be motivated to use your ideas.
One thing that I think is key to success, necessary (but not always sufficient), is an appeal to common values.
An appeal to common values goes like this:
- We both care about doing the right thing for our company.
- One aspect of doing the right thing is X (where X is a company value, corporate goal that you both share, or a common recognition of a problem that both of you want to solve). Let’s both achieve X.
- We can achieve X better if we work together than if we are working separately. We each bring our own requirements to the table. However, since the end goal is the same, collaboration is better that competition. (be ready to use measurement, logic, emotion, and/or incentive to back this point up).
- You can trust me to defend all of our requirements, and I’d like to trust you in the same way. I’m trustworthy.
Appeals to common values are effective because none of these statements is particularly difficult to agree with.
For example, in Microsoft, we have company values that say that we will take on Bold Challenges. We also have policies that say things like “use our own technologies where possible to solve our corporate needs.” I can use both of these together to convince someone to adopt a new technology in an upcoming project, even if it adds some small project risks, because I can tie that activity (“use a new technology”) back to shared values (“use our own stuff” and “bold challenges”).
The fourth item above is probably the biggest part of the “appeal to common values.” If we are working together to collaborate, at some level, we must trust one another. My requirements and your requirements must blend. We must both be accountable to all of the requirements, and we must both defend the other person’s requirements when our shared solution is challenged. Otherwise, collaboration is a farce.
This is sometimes overlooked, but without trust, an appeal to common values may produce no fruit. On the other hand, without common values, collaboration can be difficult, or impossible, to achieve.
The single hardest thing to get a
person to do, is think.
If you can get a person to think, the next most difficult thing to get them to do is change.
Therefore, if you want people to change,
don’t ask them to think.
My father used to tell me, “You have two choices: getting someone to think, or getting someone to change. Asking for both is asking for the moon.” My father had a good bit of experience with both… he was a college professor. A good one at that.
Of course, a college professor can consider himself successful if he gets someone to think. Not so much for an Enterprise Architect. We have to be able to go either way. Sometimes, it is the job of an EA to get someone to think. Other times, it is our job to get someone to change.
Thinking is tough. If you show a business leader that a particular counter-intuitive action is a direct result of their own strategies, they will have to think about it… or just trust you. That is the advantage of being a trusted advisor. If the business leader trusts you, he can take the easy way out. He won’t have to think, because you’ve shown him that you can be trusted.
Change is tough. In many organizations, Enterprise Architecture is not well integrated into normal planning and alignment processes. You may have to ask people to perform tasks in a different order or to use a different set of inputs than they are used to. You are asking them to change.
The key here is not to also ask them to think. Plan out the steps and walk them through those steps. Show them how to do the “new” work. Help them to understand why the “new” work is more valuable than the old work through any of a dozen different techniques (reference wins, emotional appeal, hope, common values, support for shared goals). You aren’t asking them to develop the new process. That would require thinking. You are asking them to do, not think, and giving them the steps.
Thinking or changing… pick one. As an EA, know what you are asking for.
“Waiter, Waiter!”
The customer sat in the corner of the busy cafe, with a seaming bowl of soup, frantically waving to the retreating waiter who had just set the bowl down and hurried away. Frustrated, he turned, but did not advance.
“What is it, sir?”
“Waiter, try this soup,” the customer replied.
Curious, he walked back to the table. “What is wrong with it.”
“Just try the soup.”
“Sir, is there a problem?” the waiter impatiently insisted, looking over his shoulder at the other tables.
“Just try the soup,” the customer repeated. A few seconds of silence passed. The waiter considered his options.
“OK, sir. I’ll try it.” The waiter looked around the table. “Where’s the spoon?”
“A-haaaaaa” noted the customer.
I spent about two hours yesterday in a conference call with the Enterprise Architecture team of a large financial institution, one of the many fringe benefits of this job. I shared some details about our EA practices and they shared theirs. It was an opportunity for me to speak with peers, share ideas, compare practices, and such. (Special thanks to their Microsoft Account Manager for setting up the conference call).
One question that came up, that in fact often comes up, is “how do you convince senior business leaders of the value of Enterprise Architecture?”
My answer: I don’t. Enterprise Architecture, the function, is not valuable by itself.
Enterprise Architecture is valuable because of the data that EA collects, and the reports that EA makes available to senior leaders. Allow me to repeat, it’s all about the data.
Business leaders don’t need Enterprise Architects to stand around acting smart. They need data, reports, and analysis. The Enterprise Architect is essential to interpret that data, and help them to understand the value of the using the information to make decisions.
So, if I have a business leader who does want data, I start there. I collect a little data and show it to her, and whet her appetite. I ask what questions she wants answered (“Which processes drive the most cost to my department?” or “How much of my budget, last year, was actually spent on going after my priority strategies?”). Then, get the subset of EA data needed to answer that question. Projects grow from projects, functions from functions. Data maintenance is expensive, so the reports have to be valuable year after year.
When we see a business leader that doesn’t understand EA, we show the reports we created for other leaders. It’s all about the data.
To be honest, I don’t want to ever sell the value of EA to a business leader. I want one business leader to ask another, “where did you get that data,” and have the other reply, “From Enterprise Architecture, of course.”
The system should flow from it’s own success.
If the data is the food, EA is the spoon.
Recently, Tim Westbrock asked, in his blog, if we should drop the term “Enterprise Architecture” when referring to the strategic business planning perspective within the EA role.
“The question that I will leave you all with is this: Can EA be successfully evolved to become a tool of business strategic planners, senior executives and boards of directors if we continue to call it Enterprise Architecture?”
To which Adrian Campbell replied, in his blog, that EA shouldn’t change its name. Instead, Enterprise IT Architects (the term he applies to technical architects) should stop calling themselves Enterprise Architects. Adrian argues:
“I would say that there has always been a difference between Enterprise Architecture and technical architecture.
The former has its origins in the Zachman Framework which has always included the business architecture aspects.
Technical architecture has evolved to become IT architecture and IT planning.”
Adrian is a smart guy. He frequently conveys interesting and insightful viewpoints based in deep experience. Unfortunately, he is rewriting history a little bit. John Zachman was part of a team that developed the entire idea of Enterprise Architecture for the expressed purpose of aligning technology to business process, as a service offering that could be provided by IBM to allow their consultants to be more valuable to their business clients.
In other words, John Zachman invented a taxonomic framework useful for both Enterprise IT Architecture and Enterprise Business Architecture. They are both in there. So using John Zachman as an argument why “upstart” IT Architects shouldn’t evolve into Enterprise Architects is an argument that is ill-informed at best.
Other professions don’t change their names when they mature. They create professional organizations, create standards, train practitioners, and police their own ranks. Physicians of old are not physicians of today. Engineers of old are not engineers of today. Pharmacists of old are not pharmacists of today. Professions change and grow.
One thing that we do see as professions grow up: specialization. Within the profession of medicine, we have seen a proliferation of literally hundreds of specialties. A pediatric oncologist would not say that a cardiologist is somehow “not” a doctor!
If it is a ‘problem’ that folks who work in one area of the Zachman framework have become aware of another area, and that is driving a desire to change the name, does that solve the problem? Adrian finishes his post with “A sheep in wolf’s clothing is still a sheep.” So if the wolf changes it’s name to “zebra”, won’t the sheep claim that it’s a zebra? The entire debate seems silly, and a little xenophobic.
As we grow, as Enterprise Architecture develops, we need to provide for the possibility that many specialties can exist in the same profession. One specialty will explore the art and science of developing business architecture. Another will explore IT alignment in funding and planning, and another will explore technical architectures for IT systems. More may appear.
Our frameworks are big enough to handle many specialties. The question is: are our hearts?
Now that the president and the United Way have teamed up to proclaim that 9/11 shall be honored, each year, with a national day of service and volunteerism, Microsoft jumped onto the band wagon in large numbers.
Thousands of individual Microsoft Employees signed up for our annual Day of Caring activities, a tradition that goes back to the early days when Bill Gate's mother used to lead the United Way in the Seattle/Redmond area.
I'm proud to be one of them. Many members of the Microsoft IT Technology Office, including CTO Barry Briggs, personally took part in activities to support a local charity that provides trained assistance dogs to handicapped individuals (For more information or to support Summit Assistance Dogs, please see their site at http://www.summitdogs.org/). It was a morning of scrubbing kennels, bathing dogs, general maintenance, and learning about ways that we can support their good efforts.
It was also a chance to get out into the community and show that Microsoft cares. Microsoft's support for charity is amazing. As an employee, my contributions to non-profit agencies are matched, dollar for dollar, and my volunteer time is even matched with financial contributions from Microsoft. I can submit records of my contributions, or, if I'd like, I can sign up to have automatic deductions from my paycheck made available directly to the charities of my choice (which I do).
That level of support really makes a difference. As a Microsoft employee, I have given more to various charities in the last five years than in all prior years of my career combined. I'm more proud of my employer, on the Day of Caring each year, than at almost any other time.
Microsoft, on days like 9/11, proves to me that it cares about being a good citizen, contributing to the communities around the world where Microsoft can make a difference, and for that, Microsoft earns my respect and praise.
I mentioned to a Christian friend of mine, yesterday, that I consider him to be a “mensch.” He was unaware of the term, and it made me wonder what other folks say about the becoming and being a mensch. I ran across Guy Kawasaki’s blog post on the topic, but to me, his post didn’t really provide the meaning that I’d look for.
First off, the word Mensch comes from the Yiddish and literally means “man.” The real meaning is deeper, because, to be a Mensch means to be a “Good Man.” The Oxford English Dictionary has an excellent definition:
In Jewish usage: a person of integrity or rectitude; a person who is morally just, honest, or honourable. [OED]
So how does someone go about becoming a Mensch, and remaining one? To me, there are a small number of rules:
1) Treat each person you meet in the manner that all people should be treated. This goes beyond treating someone the way you would want to be treated… the golden rule. I am a forgiving person. If someone is rude to me, I forgive them. But no one should be treated rudely. To treat others as they should be treated is a higher calling. It means to consider how all people should behave: to imagine the world that G_d would want us to live in, and then live there.
2) To be an example to others of how people should behave. This is a kind of humble leadership that implies that you behave as if a small child is watching you, learning from you, emulating you, each moment of the day. That doesn’t mean to be perfect, but it does mean to be self-aware. Do nothing that you wouldn’t want your son or daughter to be able to stand on stage, as a valedictorian, and cite as an example of your leadership.
3) To perform acts of love and kindness expecting no reward or recognition. This goes beyond anonymous donation to good charity (although that is a wonderful thing to do). This goes to everything from small kindnesses to your neighbors, to acts of random kindness to strangers, to moments of honest forgiveness to those that have wronged you.
4) Seek out those that you have wronged, and apologize. There is a ritual among Jews. Each year, as Yom Kippur approaches, each Jew is to actively seek out the people that he or she has wronged, apologize, and do their best to right the wrong. An excellent post on this topic is here. This is a huge part of being a mensch to me. This act is one of the most humbling things you can do. I recommend it to anyone, not just Jews. You will feel better for it.
5) To heal the world, deeply and meaningfully. There is an old tale of how the world was perfect once, but it has been cracked and broken. Each person has a responsibility to heal it, to find a place where your special gifts allow you to close a wound, right a wrong, or stand up for the weak, helpless, or powerless among us. Tikkun Olam. Heal the world. This does not mean that you have to help a thousand people. You can help one deeply troubled soul. Or you can teach, or feed, or clothe, or protect, or defend, or support. Do what your gifts allow you to do. Grow your gifts… nurture them… become the best you can be, so that you can heal the world in the best way that you can.
That, to me, is what it means to be a mensch. To be humble. Good. Worthy of emulation. Kind. Honest. Loving.
One day, I will die and be buried. The one thing I want someone to say of me, in honesty, is that I was a mensch.
Let’s say that you have two systems: Adipose and BellyFat. They both need the same information. Adipose handles customer transactions, so it needs information about customers. BellyFat handles the long-term management of customer information, like what products they have purchased and what rights they own. It also needs information about customers.
How do we keep the customer information, in these two systems, in sync? SOA offers three answers: Call-and-Response, Optimistic Data Sync and Pessimistic Data Sync.
- Call-and-Response says: One system holds the data. The other does not. The system that does not hold the data calls the one that does, on a real time basis, and gets the data back quickly and efficiently.
- Optimistic Data Sync says: Both systems keep a copy of the data. If an event happens in either system, drop it on the bus. The other system will get the event, interpret it correctly, and update its internal store to reflect the change.
- Pessimistic Data Sync says: One system masters the data, but the other system keeps a local copy. If an event happens in either system, drop it on the bus. The other system will get the event, interpret it as best it can, and update its internal store according to its own business rules. On a periodic basis, the ENTIRE data structure will be copied from the master to overwrite the data in the local copies (data refresh).
Each of these three has its own strengths and weaknesses. One of them, Optimistic data sync, is so bad, however, that I’d like to call it out for special ridicule.
| Type |
Advantages |
Disadvantages |
| Call and Response |
- Any data entity exists once
- Less duplication of data, lower physical storage
- One view of the “truth”
- Diminishes need for ETL capabilities
- Easy understanding for software developers that are familiar with relational database design
- Consistent inter-system data models not requireed
|
- Constrains architecture – provider and consumer must be “close”
- Requires highly available data providers
- Cumulative negative impacts on overall ecosystem reliability
- Requires highly scalable messaging infrastructure
- Fosters point-to-point messaging
- Leads to rapid increases in complexity and management cost
|
| Optimistic Data Sync |
- Allows multiple systems to “master” a data entity
- Diminishes need for ETL capabilities
- Encourages loose coupling between systems
- Supports systems that are wide distances apart.
|
- Requires highly scalable messaging infrastructure
- Requires highly reliable messaging infrastructure
- Assumes that data updates are always consistently applied
- Data gradually gets out of sync, with no recourse to get it right.
- Consistent data models are a necessity
|
| Pessimistic Data Sync |
- Does not require expensive messaging infrastructure
- The amount of “correctness” between systems can be carefully managed
- Encourages loose coupling between systems
- Consistent inter-system data models not required
|
- Requires system architects to agree that one system is a master
- Data gradually gets out of sync, but administrator can use refresh mechanism to resync
- Requires ETL capabilities
|
You will choose one over the other depending on your tolerance for the “disadvantages” and your preference is for the “advantages” of any method. However, and this is the focus of this blog post, one of these three is really not workable in the long run: Optimistic Data Synchronization.
The reason for my enmity for this approach is simple: this approach uses an underlying assumption that is poorly considered. That assumption is that it is fairly easy for two systems to stay in sync simply by keeping each other abreast of all of the events that have occurred in either one.
The problem with this assumption is that it is NOT easy for two systems to stay in sync. If the two systems don’t share an IDENTICAL data model, then each system has to interpret the messages from the other. The rules of that interpretation have to be coded in each system, and that code must stay perfectly in sync. Plus, there can be no errors in interpretation, or variations in the way that a change propagates throughout the recipient’s system. There can be no variations in the event model between the systems. No bugs either. Sure…. if we can get to the point where no humans are involved in writing computer applications, then this might make sense.
Not long ago, I used to think that Optimistic data sync was a good idea, and that SOA developers should assume that their data exists outside their systems. Heck, I used to think that call and response was a good idea too. Both are bad in practice, with Optimistic sync being by far the worst. There are just too many common scenarios (like one system going down for a period of time, and coming back up after missing some messages) that drives down the overall integrity of data managed in this way.
While I’d go so far as to say that Pessimistic and Call-and-Response are reasonable patterns for a SOA architect to select, the optimistic data sync method should be considered an anti-pattern, and avoided as much as humanly possible.
The Zachman framework for Enterprise Architecture is often compared to the periodic table of elements in Chemistry. Both contain items that can be used to construct a wide array of useful things. Both contain elements that can be understood in rows and columns with properties applied to each. Both allow you to predict the existence of an element before one is discovered.
Both claim comprehensiveness. In chemistry, you cannot describe any substance made of matter without referring exclusively to the elements described in the periodic table. In architecture, according to some enterprise architects, you cannot describe any architecture without referring exclusively to the elements described in the Zachman framework (ZF).
Unfortunately, this leads to some confusion when it comes to capability mapping. Business capabilities are a tool used by enterprise architects and business architects to understand and model businesses.
But here’s the rub: business capabilities do not appear in the Zachman framework. This causes confusion among new architects first learning the Zachman framework. The confusion goes like this: If the ZF is comprehensive, and defines everything that an architect needs, then why does an Enterprise Architect need a capability? Are capabilities non-architectural? Should the notion of capability mapping be disregarded by Enterprise Architects because capabilities are not part of the comprehensive Zachman framework? Should the development of a taxonomy of capabilities be considered a pointless exercise because it isn’t architectural?
Hmm…
Consider this: Water (H2O) is not in the periodic table of elements. Obvious, right? After all, why would a molecule, like water, appear in a table of elements? It wouldn’t, right?
But there are taxonomies, in chemistry, that include water. There are taxonomies of molecules, taxonomies of liquids, taxonomies of solvents, etc, each of which include the molecule H2O that we know of as water. A “molecule” is a core concept in Chemistry.
Similarly, a business capability is an architectural concept that does not exist in the Zachman framework. It could be said to be a compound concept, just as the concept of a molecule is a composition of atoms. A specific instance of a molecule is Water. A specific instance of a business capability is “Lead Generation.” In the same way that a molecule is an abstract composition of atoms, a capability is an abstract composition of roles, processes, technologies, and entities.
So, are business capabilities part of enterprise architecture, even though they cannot be seen on the Zachman framework? Yes. For the same reason that molecules are part of chemistry. A framework can define and categorize the raw materials, but it doesn’t define all the USEFUL, RELIABLE, and STABLE combinations of elements that we live with, work with, and communicate with every day. It doesn’t even define the rules necessary to combine the elements. (in EA, a metamodel does that).
Please don’t misunderstand. I’m not bashing the Zachman Framework. A taxonomy of elements is necessary, but it is not sufficient. You can understand a lot about chemistry by using the periodic table, but you cannot do gene mapping or work in AIDS research if you limit yourself to that single taxonomy. You need those long (sometimes very long) taxonomies of useful, reliable, and stable combinations in order to draw conclusions about your work, organize your efforts, and find the answers you need.
For the same reason, capability hierarchies are necessary, nay, essential to modern Enterprise Architecture. A capability hierarchy is architectural, because it is useful to architects, used by architects, and fundamental to some architectural methods. Is any such taxonomy perfect? Why should it be? In the real world, a list of things doesn’t have to be completely known, or even completely knowable, in order to be useful.
We are all familiar with the notion of a work-back schedule: a date driven schedule where we start with the end in mind, and work back to the present time, figuring out what tasks we can accomplish in that time frame. Anything that doesn’t fit, we don’t do. Creating a work-back schedule is an iterative process. You describe the results at the beginning, but if you cannot deliver those results in the time you have, you figure out what you CAN deliver.
I was having a chat with another architect today who asked why we don’t do this for enterprise architecture… and I didn’t have a good response for him. My viewpoint has often been to solve a small problem and “scale out,” (kind of EA + Agile), but his question was interesting…
Why don’t we jump ahead, four years, and describe the “Ideal” state, and then WORK BACK to today, describing what each of the steps would be to get there. And then iterate. If we cannot get to the “Ideal” state in four years, answer the question “What can we do in four years?”
All too often, I’ve seen enterprise architecture described from the “Ideal” state with no respect for time. It is as though the Ideal state is some goal hovering out in the ether, with no connection to reality. Thus, it is easy to criticize EA as being detached from reality, because the models ARE detached from reality.
What may simply be a better approach is to describe an Ideal state based on principles and best practices, and then temper that with a work-back process, just as we would for a time-bounded project plan.
With a work-back approach, the EA team could create multiple possible “future” states and get IT leadership to pick one, rather than having everyone buy off on an ideal state that is pretty, but unrealistic.
Once you have an attainable “future state” model, then hide the “ideal state” in a desk drawer. Don’t refer to it. Use the realistic version that is actually reflective of the budget, appetite, skills, flexibility, and political realities of the IT organization.
The realistic model becomes the “future state model” that is discussed, and described, and shared, and evaluated. It is the one you discuss because it is possible, not because it is “right” or “ideal.” Possible trumps Right.
Simple. Makes sense. Yet, in all the discussion of EA that I’ve read and walked through, including the various EA frameworks that I’ve studied, I’ve not yet seen a description of using a work-back process to describe the future state for EA models.
What are your thoughts? I’m interested to know.
There is an odd relationship between the concepts of a use case and a requirement. A use case is a structured chunk of text, useful for understanding and evoking requirements from the end user. It is also a way to place those requirements into context (as in “this requirements is attached to step 3 of UC41”). There is also the “flow” itself… the order in which information is entered and the “screens” that the user enters them into. In many cases, a use case is quite explicit about the flow, and the customers will spend a good bit of time describing that flow. In other cases, the flow is incidental.
So, I can see three types of “requirements” that are part and parcel of use cases:
- Declarative requirements attached to the use case: these “statements of requirement” may be implicit in the structure (as is the case with preconditions and post conditions), or may be attached to the use case itself. For example, if we are creating a workflow system, we may see a declarative requirement attached to a use case saying something like this: “When a user logs in to the workflow system, the default screen is the task list.” The interesting thing is that this requirement could be attached to any of a dozen different use cases. It is universally understandable.
- Implicit requirements attached to a step in the use case: these are requirements for user interaction, data fields, and functionality that are implicitly stated by the description in the use case, without being declared. For example, if we describe a use case in a workflow system where a person can “assign” a task to someone else to perform, we could see a step like this: “Step 3: from a drop-down list, select the name of the person to whom this task will be assigned, or enter their name in the text box”. From that, we could create some declarative requirements like “users may assign a task to another user,” “the user will be presented with a list of team members to whom it is appropriate to assign a particular task, based on the task type,” and “the user may enter the name of a person to assign the task to.”
- The flow of the steps in a use case: In the use case description, the business analyst is describing a sequence of steps that the user has to go through in order to perform a specific task (or, as I like to say, complete a specific system interaction). That sequence itself, with the implicit order of “what information is provided first” and “what information is provided next” is often created by the analyst without regard to the difficulties of asking for information in that particular order.
I specifically want to focus on type 3: implicit order. The analyst creates this order. In some cases, the order was created in order to “tell a story” and it is NOT a requirement from the end user… it is a requirement from the analyst. In other words, the customer doesn’t care about the order itself. In other cases, the customer and the analyst will carefully create that sequence of steps, focusing time and attention on the order in which information is provided. The customer cares a great deal about the order of information (usually for valid reasons).
Here is where there is a potential for misunderstanding. When a use case is delivered to a development team, the analyst needs to make it clear whether the order of steps is a “useful story” or a “well considered requirement.” This indicator is missing from nearly every use case I’ve ever seen described, yet there is an interesting effect here. Developers will read a use case and will make decisions, in code, on the basis of what they see. Some will take all sequences in the use case as a verbatim requirement, even when it is not necessarily a requirement from the customer. Others will look for ways to create interesting and insightful interfaces, regardless of how hard the analyst worked to create the use cases.
Testers have a problem with either option, because they are often out developing test scenarios and estimating test effort from the requirements, without consideration of the developer’s choices.
And a developer who takes the flow of a use case as a verbatim expression is the kind of developer that would never have developed the original iPhone interface, because no analyst in the world could have designed that. The iPhone interface was developed by a design team that took the time to reconsider every aspect of user input on a touch device. It was not dictated by a business user through a use case process.
Suggestion for improving the standard structure of use cases:
There should be an indicator of some kind attached to the use case that says one of the following options is available to the design and development teams. Let’s call this indicator “Requirements for Flow Design” and the indicator will have one of the following values:
- Specific – the analyst and the customer carefully considered both the order of steps and the interface controls that they want to see, and the developer should follow the flow and controls described as closely as possible.
- Sequenced – the analyst and the customer carefully considered the sequence of information and interaction, but the customer is flexible on the interface controls that the developer may use when implementing the flow.
- General – the analyst and customer agree with the flow, but are willing to consider any alternative flow that meets other requirements for information and functionality.
- Suggested – the analyst created the flow as a story to elicit requirements. As long as other requirements are met, the flow is optional.
This removes some of the guesswork about “customer intent” that is inherent in present use case design.
Even non-geeks will get a huge kick out of this, and I’m betting that most of the folks who follow my blog will find it as funny as I did… Word up.
My only question for the MS Marketing guys who finally loosened up enough to pay for a viral video: What Took You So Long!
Special kudos to Traffik, the agency that did the work. Excellent Job!
I had the opportunity recently to review an excellent article in the Harvard Business Review (HBR) on strategy development, and consider the notion of a business motivation model with respect to how a strategy is constructed. (“Can you say what your strategy is?” by David Collis and Michael Rukstad, Harvard Business Review, April 2008, link)
For those folks who are not familiar with a business motivation model, the goal of this kind of architectural artifact is to understand the different “things” that motivate an enterprise and trace the various behaviors of the enterprise that are engaged (or not engaged) to react to those things. Things (not a technical term) refer to influencers like competitive opportunities, drivers like strategies and objectives, and business models that describe the elements of the business itself.
One thing that is clear: traceability matters. Traceability is the ability to not only say “what” we are doing, but “why.” It is the ability to trace our activities back to motivators that we can all agree on.
The HBR article cited above provides a clear argument for rewriting strategy statements in a different way, one in which the traceability of the strategy is described in the strategy statement itself. For example, it would be “OK” for a ‘printer’ company to use a strategy like this:
“Increase market penetration in the North America SOHO segment by 20% through improvements in product usability, partner marketing, and customer relationship management.”
On the other hand, according to the article, it is even better to lengthen that sentence dramatically. An appropriate rewrite would include, in the strategy statement itself, the traceability to a key differentiator for the enterprise:
“Increase market penetration in the North America SOHO segment by 20% through improvements in product usability, partner marketing, and customer relationship management leveraging our long-term relationships with customers and deep awareness of their business needs.”
I must confess that it makes sense to care about this particular aspect of strategic traceability. After all, creating a strategy that does not trace to a fundamental motivation around improving the health, competitiveness, and financial stability of a company would be particularly corrosive. A bad strategy can be worse than no strategy.
The solution that the authors suggest is useful in an environment where the business does not already know who they are, and what aspects of their business are key differentiators for them.
If a business is very aware of their key differentiators, then extending the strategy statement to include them is redundant and, dare I say, mildly counterproductive. The notion that a long-winded sentence carries sufficient weight to drive a change, outside a complete understanding of the business itself, is indicative of two possibilities: (1) an enterprise with only one business model, or (2) a business with fairly chaotic thinking.
In effect, if your business is very simple, but you don’t believe that everyone understands it, then this is good advice. Also, if your business is in chaos, this is excellent advice. In both cases, you need the strategy statements to communicate and provide clarity.
On the other hand, if your business is well organized but competes in a rapidly changing business environment, using a complex multi-faceted set of business models, then I have some concerns.
The limitations of sentences
Long sentences as strategy statements are a good idea, if there is no conflict between them. In a business with one business model, this is a realistic goal. It would be inappropriate for the leadership of the business to issue strategies that overlap or compete with one another if there is only one business model.
On the other hand, many businesses, including Microsoft and most of the rest of the Fortune 100 corporations, have many business models within the framework of their enterprise. These different businesses will have overlapping customer bases, different products, and potentially some radically different ways to make money. For example, as Microsoft embarks on Software Plus Services, we make money on the sale of licenses of Microsoft Exchange. We also make money on selling access to an online version of Microsoft Exchange (Business Online Services) that many businesses find preferable to running their own e-mail infrastructure.
You can add only so much clarity to a business by stretching out the length of the strategy statements to include additional words, as the HBR article suggests. Some things cannot be worked out using long sentences, however. Long sentences to do not clarify overlaps, or what may appear to be competing strategies. Long sentences do not reduce internal conflicts or clear up customer misconceptions or make it easy for the sales force to explain what your company does, especially when your company does MANY different things, for different people, in different ways.
Perhaps having longer strategy statements do work in chaotic businesses. I’m not sure. I believe that the problems of poor role understanding, poor organizational discipline, and poor visibility into the success factors of others are each big problems typical of a chaotic business. If it were my call, I’d want to solve those problems before I focused on clarifying business strategy statements (although, in some sense, clarity may help).
Traceability through models
So let’s assume, for the rest of this discussion, that you can drive behavior from a strategy because your business has the organizational discipline to actually care about these statements. Let’s assume that the problem is this: you need your strategies to be executed better.
Now, let’s throw in a complicating factor: your enterprise has many business models… many different ways to make money. If that is the case, then there may be effective ways that work for more people, in more ways, than the one suggested in the HBR article.
One method for building effective, aligned, and actionable strategies to model the business using a rich mechanism like the Enterprise Business Motivation Model. This allows direct traceability between the competitive needs of the business model, the influencers that affect the business, and the drivers of change that propagate through an organization.
The method advised by the HBR article performs some of that traceability. According to the article, some of the differentiation of the business needs to be drawn into the strategy statements themselves. This is not bad advice. However, the author is selecting one particular path of traceability (product differentiation to strategy) and neglecting others.
With a model, you can draw this path, and many more. Modeling is necessary because business strategies are simply one of the tools of change, and a full and rich motivation model, like the one described in the MSDN article, clarifies the traceability without sacrificing all of the relationships in favor of a single important one.
Having a full model doesn’t fix a chaotic business, but it is a useful first step. On the other hand, a business without a rich and fully described motivation model will have a harder time reaching the maturity that they need in order to compete, and succeed, in the marketplace.
Once you have developed the model, you have something very valuable. The model lets you demonstrate how the strategies are connected to the various influencers, in the context of the (potentially many) business models of an enterprise. It provides much of the rich context needed to prioritize business objectives and deal with competing demands for resources, time, and mindshare. With a broad notion of traceability in place, the need to “pad” the strategy statements themselves may diminish. More importantly, strategy statements can be shown to derive from many different paths of traceability, not just one of product differentiation.
Conclusion
The advice from the Harvard Business Review is good advice. There are many situations where a set of long strategy statements is a good thing. Companies that want to use strategy statements as an education mechanism, and not just a motivation mechanism, can use their advice to full effect.
The HBR article does not, however, take into account the many interesting kinds of traceability that may be useful to the business. A full and rich motivation model can start where that article leaves off and go much further, allowing the business to describing its motivating factors in more than one manner (regardless of how useful that manner is).
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.
For most of the last decade, we’ve seen a steady growth in the use of a simple “recommended practice” in the world of software architecture. Well known by it’s designation, IEEE-1471 is officially titled “Recommended Practice for Architectural Description of Software-Intensive Systems.”
The standard defines words, mostly. It answers the question: “What is Software Architecture” and does so in a simple and elegant manner using the concepts of model, view, and viewpoint. It is also written in somewhat vague language, with the meaning of some terms being assumed and others inconsistently applied. Creating a conceptual model from this document was no simpler than creating a model from a typical business document, even though it should have been.
Regardless of the relatively minor deficiencies of IEEE-1471, we find it a useful way to describe software architecture and our team in Microsoft IT has fully embraced the language and concepts of this simple and elegant approach. In addition to embracing 1471, we extended 1471 by linking in key concepts from the UML, as well as other notions like “common viewpoint types,” “architectural description methods,” and modeling languages.
A number of months ago, I created a small poster (designed to be printed in Tabloid size or larger on a color printer) that illustrates the value of this simple language. Embedded in that poster is a conceptual model that illustrates what these terms mean in relation to one another. I’m sharing the poster here, for others to benefit from.
My goal is to provide a simple way for all architects to illustrate, share, learn from, and talk about the language of software architecture. I hope that this poster finds its way into classrooms and team training sessions. Feel free to use the poster as a way to communicate and share. I did not author these concepts. I’m simply trying to explain them.
Note: the diagram uses some of the notational conventions of UML, but not many. If you understand the concepts of association, composition, and aggregation in the basic class model, you can read this diagram. The verbs on the lines between concepts are written so that a reader can read the association by following the arrow.
If you’d like the IEEE-1471 Extended diagram, without the rest of the poster, simply click the image below.
