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.
About a month back, I asked if it was time to create an MBA in Business Architecture. I’m going to follow up with a suggestion for a curriculum for such an odd degree.
The degree is provocative on its face. After all, an MBA is first and foremost, a business degree. Yet most Enterprise Business Architects are employees of IT departments. How do we mix the two?
I honestly believe that the core business skills focused on in the MBA are necessary but not sufficient to be a good EA. I believe that core technology skills are necessary but not sufficient either. You need a mix of both.
A good EA needs to be able to operate in both spheres: business and technology. They need to have excellent skills in both. That is why I wonder if the program at RMIT in Australia is sufficiently business oriented. On the other hand, the McCombs school of business in Texas has an undergraduate degree that mixes business and engineering. That seems interesting. There is also a university in Switzerland that has a degree in Business Engineering, but I couldn’t get many details.
The following curriculum suggestion was derived from two primary sources. The first is the Austin Texas MBA program mentioned above. The second is the listed curriculum of the Harvard Business School. In a few cases, I copied the course descriptions verbatim from one of these two sites. In most cases, I modified the course descriptions to represent the “flavor” that I would wish to see for a Business Architecture MBA.
| Basic Modeling and the visual representation of business concepts |
Basic understanding of models, and using modeling to recognize, represent, and improve the information, relationships and clarity of business activities. Students are introduced to Business Process Modeling, Computer systems modeling, Conceptual modeling, and the concept of metamodels. |
| Financial Accounting |
Covers concepts and issues in the preparation and interpretation of financial statements and the use of financial information in evaluation and control of an organization. |
| Financial Management |
Examines the theory and practice of corporate finance. The focus of the course is on investment and financing decisions. Structural impacts of financial decisions are described using models. Major topics include risk and return, valuation, asset markets and market efficiency, capital budgeting, capital structure, dividend policy, agency considerations, and derivative securities. |
| Business Structural Evaluation, Modeling, and Transition planning |
Operational Models are studied, along with transition strategies for companies moving from one operational model to another. Structural approaches to the division of responsibilities and the use of incentives and scorecards to drive organizational behavior are studied. Students will be expected to develop a full enterprise model of an existing business or governmental institution from case studies and publically available information. |
| Business, Government, and Economics |
This course introduces tools for studying the economic environment of business to help managers understand the implications for their companies. Students will learn the impact of: National income and balance of payment accounting, Exchange rate theory, Political regimes, and regional global integration issues. These integration issues include: International trade, Foreign direct investment, Portfolio capital, and Global environmental issues. |
| Marketing Management |
Studies three distinct marketing issues – market analysis, developing a marketing strategy, and constructing the appropriate marketing mix for a product. The course highlights the development and visual representation of action strategies, development of products and services, establishment of effective pricing, determination of distribution intensity, and promotion of business solutions. |
| Business Process Improvement / Lean / Six Sigma |
Examines the operational measurement view of business. The first unit discusses statistical measurement systems for business. The second unit focuses on business process understanding and modeling, along with methodologies for simplifying and improving business processes. Students will be required to produce detailed BPMN models and then use Lean and Six Sigma techniques to improve them. |
| Strategy Development and Alignment |
The objective of this course is to help students develop the skills for formulating strategy. Strategy development provides an understanding of a firm's operating environment, competitive advantage, customer value proposition, activity configuration, and balancing the risks and opportunities available to an enterprise with the business strategy in mind. The first module focuses on competitive positioning; understanding comparative costs; and addressing issues such as cannibalization, network externalities, and globalization. The second module focuses on the analytical tools of business modeling, and the alignment of business structures and behavior to strategic concerns. |
| Finance Based Decision Making and the Planning of IT investments |
Illustrates the essentials of managerial planning and control, for any business function, with a special focus on the planning and management of Information Technology investments. This course examines topics like short-term and long-term decisions, activity based costing, strategic alignment, and benefits realization. |
| Negotiation, Presentation, and Influence |
This course focuses on the communication skills that are critical to the success of the Enterprise Business Architect, including the ability to negotiate for success, the ability to understand concerns and inform stakeholders at all levels of an organization, and the ability to influence the decision making and outcomes of teams outside your direct control. |
| Leadership and Corporate Accountability |
In this course, students learn about the complex responsibilities facing business leaders today. Using case studies that highlight difficult managerial decisions, the course examines the legal, ethical, and economic responsibilities of corporate leaders. It also teaches students about management and governance systems leaders can use to promote responsible conduct by companies and their employees, and shows how personal values can play a critical role in effective leadership. |
| Enterprise Architecture Models and Frameworks |
This course focuses on the history, evolution, and comparative study of the uses of various frameworks that target the enterprise. This includes discussions of the Zachman framework, eTOM, TOGAF, FEAF, MODAF, and others. The development of mature Enterprise Architecture programs, and their relationship to various business functions including Information Technology, Strategic Planning, Human Resources, and Finance are studied. |
| Business Architecture Patterns and Practices |
This course focuses on the specific terminology and practices used in the modern Business Architecture environment, including the use of heatmaps, capability maps, enterprise roadmaps, investment prioritization, IT portfolio management, Enterprise Project Management Office, and structures for corporate governance and compliance. |
Electives courses
- Business Program and Project Management
- Information Security
- Statistics for Decision Making
- Software Development Processes (from Waterfall to Agile)
- Software Operations Management and IT Service Management
- Manager’s Introduction to Software Development
- Software Development Languages and Environments
- Information Modeling and aspects of Data Design
That’s my take on a potential degree program. I know this is a bit off-topic for an Enterprise Architect, but it is good to illustrate a wish list sometimes.
Many of the folks on my Architecture blog roll have been inactive, so I've dropped them. There are other, newer blogs that may deserve attention. If you know of a blog or wiki that covers Architectural issues, and you find it valuable, please send me the link so I can add it to my blog roll. (Yes, you can nominate yourself).
The SANS institute has published a list of the top 25 most dangerous programming errors. Not only is this a must-read, but it is critical for architects, developers and testers, of all stripes, to be aware of these programming errors. Unless and until we have platforms that simply prevent these errors, we can combat these security gaps best through education, careful testing, and responsible project delivery practices.
http://www.sans.org/top25errors/
How familiar are you with these mistakes?
Would you be able to spot them in code you reviewed?
Would you be able to prevent them in your own code?
On a blog post titled “what good looks like,” Alan Inglis detailed a list of “project architectectural artifacts” that he wishes that previous architects would leave behind when a project is completed.
In his list, Alan details 10 artifacts (actually 14, if you use the ZF to catalog them) that he’d suggest should be created. His advice is interesting, but there is a flaw in the logic. I’ll examine his suggestion from a couple of viewpoints, to illustrate why I believe that his advice is incomplete, and to offer a suggestion for completing it.
Context
It is normal, when we begin a project, to detail out the things that we wish we had. Therefore, we “should” create them for the next person. Viewpoint 1: at the beginning, looking forward, defining project requirements.
It is also typical to open up a maintenance project and need to make changes, only to find yourself wondering about the choices made by the person before you. Viewpoint 2: in the middle, looking back, trying to understand. (In my past dev teams, we called this process an “archeology expedition.”)
The problem with his list of artifacts (which is quite comprehensive) is that “wishing” does not constitute a requirement. If I create an artifact “for the future” that does not mean that the people, in viewpoint 2, will use it.
Unless there is a built-in development process that REQUIRES architects and developers to visit a repository, and withdraw relevant documents, then you have no business justification for performing the task.
I question every requirement that has no business justification, especially if it is not tied to a business process. This is easily fixed: tie the documentation ‘requirement’ to a business process… the process of designing architecture.
Suggestion
People in “viewpoint 2” should have the requirement of looking things up, in a specific place, for a specific reason. We need to carefully describe the processes around this “learning” phase. Why would we look things up? What things would we look up, and most importantly, what are the triggers or scenarios in which a lookup process is required?
Let’s draw the requirements for documentation from that development process… not from a wish list.
For example: If I believe that it will be useful to create a list of terms (glossary), let’s understand the scenarios where a list of terms would be useful.
- Would it be on THIS application, or any application tied to the same business unit?
- What do I need to know about a term?
- If I look up a term, would it be natural to link that term to the conceptual data model (if applicable)?
- What about changes in the meaning or use of the term over time?
- If a term has changed, or an older term is no longer used, what guidelines must be followed to update that glossary?
- Should we keep older definitions, so that people inspecting older code can understand the code?
- Should we leave advice to those poor souls for how to interpret an older term in the context of a newer practice or process?
- Assuming many projects would use the same glossary, should we tie each term to the project or app that needed it? (That way, a term won’t be deleted if a system that needs it is still running in production).
Discussion
I picked on the glossary, but EVERY ONE of the artifacts that Alan lists would have this problem. Each describes some tiny part of a much larger ecosystem of information. The moment the project goes into production, the artifacts must take their place among the hundreds of other relevant documents, from every other project. They need to be findable, consistent, and AUTOMATICALLY linked together in a way that minimizes the “archeology expedition” that “viewpoint 2” implies.
This is no longer a “project” problem. This is an enterprise problem. The data describes part of the architecture of the enterprise, and as such, needs to be maintained at the enterprise level, for the sake of engineering.
As Leo de Sousa pointed out in his reply to the Alan’s post, a repository is required. But it won’t be a simple one, where we drop documents. No, it will be a complex thing, that understands what each architectural element is, and how to find it, and how to link it to other elements, so that the artifact of the present doesn’t become the archeology of the future.
Sometimes I hear a complaint from an IT architect who wants to have direct conversations with “the business” or “the customer” but, for some reason (usually bureaucratic), they cannot. There is a team of analysts or project managers that they are supposed to talk to.
The original objective of having “layers” of people is to make IT appear simple. We all agree that business constituents can become confused if they are dealing with a long list of people from IT, each of which have different concerns. In the worst case scenario, a business user reaches out to an analyst to tell them about a software error, and the ‘problem’ gets handed off from person to person, adding time and confusing the user.
Many companies favor the “Single Point of Contact” approach. For each business unit, there is a single point of contact for all projects. There may still be one more point of contact for “support” related concerns. But that is all. This hides some of the complexity from the business customer, but adds a layer between IT and the customer.
So where does the IT architect fit? Does it depend on the type of architect? Does the enterprise architect need to have direct conversations with business stakeholders?
What about solution or platform architects? Should they be talking “directly to the business?”
It would seem obvious that business architects should, but how do business architects relate to business analysts? There’s still the support side as well. Does each application have their own support contact? What happens when one application has the right data, and the next one over has the wrong data… who should the customer call?
So we have a problem. That much is clear. How to solve it?
I’d like to consider introducing a concept into the conversation: interdisciplinary teams.
The notion of an interdisciplinary team is not widely used in computing, but there are many examples in science. Used widely in research, medicine, and public policy, interdisciplinary teams provide a way for specialists in many fields to work together to solve a problem. Any problem can be addressed from many viewpoints, using an understanding that emerges from the unique combination of talent and responsibilities.
Many of the processes for collecting and describing requirements, including the well-understood “Joint Application Development” or JAD process, incorporate the same basic ideas, but do so in a less structured manner and only for a single “problem” (understanding requirements).
What I’d like to see done is to use the concept more consistently. For Information Technology, and for consulting, this is quite doable. Instead of having a single person represent IT to the business, have a team of people. They meet the business on a monthly basis, and the concerns of each of the people can be brought to the monthly meeting. All of this is coordinated by a single “IT Engagement Manager” or “IT Relationship Owner.” However, unlike the bureaucratic processes we see in some companies, there are a few rules that apply.
The interdisciplinary team will have predefined roles. The list of roles cannot be reduced by either the IT engagement manager or business stakeholder. One person can fill more than one role. However, the IT engagement manager does not assign IT staff to those roles. That is up to IT leadership to do.
This kind of interdisciplinary structure can allow a more direct flow of information, communication, and shared commitments than is possible with the “single point of contact” model. At the same time, the business stakeholders don’t get randomized by multiple requests for the same information or by the miscommunication that comes from collecting different information at different times in different contexts to apply to the same problem.
In many ways, using a single point of contact is an attempt to make the relationship, between IT and the business, simple. It is too simple… to the point of ineffectiveness. I believe that a broader approach is often a better one.
As many of you may know, Microsoft has a vocal and thriving Agile Software Development community. Recently, on our community forum, a question appeared about the ability of Agile development to “scale” to a large team. In other words, if we can make agile development practices work in a dev group with hundreds of people, can we make it work in a dev group with thousands of people?
There was a lot of discussion on the alias. Much focused on process improvements. E.g. how to create scrum of scrums, and how to automate test and build processes so that large systems can be integrated continuously. That is part of the answer.
However one quote, from a seasoned and experienced engineering leader, Nathan McCoy, who joined Microsoft as part of our acquisition of aQuantive , provides a real clue to the rest of the answer.
The answer is yes, agile can scale to larger systems... Here’s the quote:
When we were in waterfall mode, we tended to batch up our releases. They were complicated to plan and manage. We burned people out on death march projects that culminated in release weekends where we would work 72 hours with little sleep and little contact with our families.
We turned to agile engineering practices – in my case, not simply because I believed it would be a panacea, but rather it gave me a whole arsenal of techniques to make improvements, techniques that built on engineering practices that made a lot of sense to me.
We evolved away from the big batch release by decoupling on component boundaries, putting in services, adding contracts and other techniques mentioned often on this [forum], to the place where we have not done such a big batch release weekend in years.
Let’s look at that for a minute.
The Nathan McCoy is talking about a painful deployment process that could not scale. Early on, deployment to live servers would take hours, but as the code complexity and number of customers grew, hours turned to days. Deployment suffered. People suffered. Quality suffered.
This team turned to agile techniques, and solved their scalability problem. They did it with decoupling, interfaces, and services. They did it with architecture.
The real lesson is this: using architecture allowed an agile team to decouple various parts of a system, which enabled agility to go further. In other words, the success of the agile project depended on the addition of architecture, at the right time, in the right manner. The problem could not be solved by agile processes alone.
They solved their problem , in an agile environment, using agile architecture. What makes it agile architecture?
- The architecture was introduced through refactoring.
- The architecture supports a specific business problem, and the minimum amount was applied to solve the problem.
- The architecture was not described in a 200 page document beforehand. It was designed in small increments and expressed directly in code.
- The practice emphasized all of the principles of the agile manifesto: working code, delivered at a sustainable pace, in small quantities, with direct customer involvement, using the best practices available.
My conclusion it threefold:
- Solution architecture can be applied in an agile manner.
- As the solutions get larger or teams grow in size and scope, Agile practices alone are not sufficient to solve every problem. For some problems, architecture is required.
- Therefore: solution architecture is a necessary and critical skill for agile project teams to master.
Off topic for architecture… but startling nonetheless:
In other words, thousands of American fighters armed with the latest killing technology are taking prescription drugs that the Federal Aviation Administration considers too dangerous for commercial pilots.
http://www.msnbc.msn.com/id/30748260/
Yikes!
Science progresses on the willingness to take widely held beliefs and test them. It is one thing to say that a medicine will “cure all that ails ye” but it is another thing altogether to prove that a particular medicine will have a particular effect on health. Proof is expensive, but science does not march forward without it.
For quite a while, our team has been working diligently to increase the use of architectural models (and architectural thinking) among our IT units. There are thousands of employees engaged in developing software in MSIT, and it is not always easy to reach a wide audience and make a compelling case. Our arguments have been based on appeals to logic (clearly, it works), metaphor (it works in other areas of engineering) and anecdotal evidence (it worked on project Foo and see the benefits they got).
But at the end of the day, we have not been using science. We never ran a true scientific study to demonstrate that the use of a particular architectural practice improved the outcome of software engineering in a specific and measurable way, compared to a project that did not use architecture.
I’d like to see us, as an industry, get to the point where we can perform a scientific experiment on the efficacy of using software architecture practices to improve software development outcomes.
We’d need a protocol for the experiment, and controlled variables, to reproduce the effects of using architecture. We’d need a specific definition of what it means to “use architecture” and the specific practices that we believe will have an impact on outcomes. We’d need a clear way to measure the outcome of the experiment so that, when repeated, anywhere in the world, the experiment could produce comparable results.
And here’s the rub: I’d like to see it be something that YOU can help with. The community of architects and developers that care about things like SOA, Architecture, and Planning… we are the people who can perform the experiment in 1,000 settings around the world. We are the ones that can prove, or disprove, the hypothesis of software architecture.
If anyone has experience with this kind of experiment, I’d love to hear from you, just to see if this idea is too difficult for the community to do. Personally, I’m not sure where to start. If you have ideas, please reach out to me.
I'm a process guy. I'm not a big fan of the claims of process management software, but I'm a huge fan of developing and using process models to organize the activities of people, and then to drive the requirements for software from those models.
So when I was asked to look into the processes for Strategic Planning (one of the three business functions of enterprise architecture), I took a process oriented approach. I looked at each of the different activities that have been suggested or planned or were being performed in strategic planning. I created a chart of inputs and outputs and linked it up so that the output of one activity is the input to another. Normal stuff.
Without going into the details of the result, I would like the share the huge reliance that all of the activities have on a basic understanding of what the business is and does. It became obvious when we began to trace back the core element of strategic planning: the business goal.
Strategies chart a path to a business goal. Both the OMG Business Motivation Model, and my Enterprise Business Motivation Model, say this same thing. A strategy is a statement of "how" a business can reach a goal. But beneath this statement, we have to recognize something even more fundamental: that an enterprise can have more than one business.
Let's say that your company is a clothing retailer. If you are successful at all, you probably have one or more "lines" of clothing that are made for you, and sold only through your stores. That is differentiation. You also may have clothing that is made by a well-known manufacturer and is sold widely, including in the stores of your competitors. (this applies to other products, not just clothing, but I'll stick with the scenario for now).
How many businesses are you in? If we want to look at the strategies of your business, it matters. This is because the strategies that may make the "custom made clothing" business successful may actually work against the "name brand retailing" business. A strategy to promote the in-house brands may hurt relationships, or drain resources, or drive down prices of the name brand products.
So before you can even write down a strategy, you have to write down the number of businesses that you are in, and then, when you write down the strategy, you write it down in context. You say "this is a strategy for making Business 2 meet it's goals." You may not know if that strategy hurts "Business 1." Depending on the organization of the business, and your responsibilities within it, you may not actually care.
But the business architect must care. The business architect, in this example, must be able to say "you are in two businesses, and they sometimes compete for resources, customers, and market-share."
So as you look at your strategic planning processes, don't forget to take the time to chart out how many businesses you are dealing with. It is such an important part of the "first step" to strategic planning.
I started two good blog posts today. Both will wait for another day, as I take this space to say goodbye to three colleagues friends from my department who were laid off today.
Gentlemen, I am sorry to see you go. I consider myself blessed to have had the opportunity to work with such talented, intelligent, and gracious individuals. We worked on some great projects together, and from each of you, I’ve learned many things. Please stay in touch and let me know where you land.
To my readers, I’ll wax philosophic another day. Today, I cannot.
[update: 7-May-09 I've just been informed of the layoffs of three more friends in other teams. One name is familiar to the blogosphere. The others were simply excellent employees.
I cannot say that this process has been anything less than personally painful.]
To all those who have lost their jobs, in Microsoft and every other business or organization this past half year, I send this famous Irish saying:
"May the road rise to meet you,
May the wind be always at your back,
May the sun shine warm upon your face,
The rains fall soft upon your fields,
And until we meet again,
May God hold you
In the palm of his hand."
B'hatzlacha - Good Luck
In many ways, the task of creating a complete roadmap for the evolution of an enterprise architecture is similar to the task of creating an optimum path to solving rubik’s cube. With rubik’s cube, the number of total possible combinations of faces is very large. (There are 43,252,003,274,489,856,000 different cube positions).
Yet, a number of years ago, Herbert Kociemba published an algorithm that would not only solve Rubik’s cube, it would do it very quickly. (You can download an easy-to-use application that provides you with a solution from his web site.) His most recent version of his app would solve 7,000 cubes per hour!
So, if it is possible to create a pathway from nearly any combination of Rubik’s cube to a “clean” solution, in 21 moves or less, and to calculate the “roadmap” in less than a second, why is it so difficult to describe the optimum pathway from a “present state” enterprise architecture to a “future state” enterprise architecture?
The advantage that Kociemba had was that the “clean” or “solved” state was fairly easy to describe. All sides have the same color. The “clean” state of an enterprise architecture depends on a lot of things, and there may not be one answer. There can be many “right” answers, each describing a unique configuration of systems, data flows, events, interfaces, technologies, and business process activities.
Another advantage that he had: the solution path did not have to be suitable at any particular step of the way. In other words, you could create any configuration of the cube, at any step, as long as the final configuration was that of a solved cube. Not so with an Enterprise Architecture. At each step of the way, we have to have an environment that is functional and, in most cases, just as capable as it was before the last set of moves was made.
Even with all these constraints, the mathematical feat of solving Rubik’s cube in an optimum number of steps has been accomplished. I don’t believe that it would be more difficult to solve for the “optimum” enterprise architecture. A different problem, true, but one of similar complexity.
Now, there have been “tried and true” methods for solving the cube for years. I learned one when I was a teenager. Regardless of how the cube started, you could follow the set of patterns and, in about 150 moves, you could solve any cube. Kociemba provided us with an optimal path that was NOT a “mathematical reduction” of the tried and true methods.
And perhaps that is the more interesting result of making this comparison. We should not expect that the optimum architectural roadmap is a simple reduction of the “tried and true” architectural roadmap. In other words, for any environment, if you describe all the moving parts, the steps needed to get you to a simpler, less expensive environment may not be obvious. More importantly, you cannot describe a “long path” and then simply “shorten” it by substituting simple sequences of moves with shorter sequences. There may not be a short cut to the optimum solution.
So the next time I hear an architect or a product salesman tell me that they have the “perfect” solution to my problem, I’m going to think about Rubik’s cube, and Kociemba. The “optimum” solution may not be the obvious one.
The dark cloud of the economic downturn has produced a silver lining within Microsoft IT: an increased emphasis on Agile development techniques. This does not mean that MS IT is new to using Agile. Far from it. Agile development practices have been used in various IT groups here for nearly a decade.
What is new is the desire to address the basic development and governance processes themselves to remove the “Bias towards Waterfall” that exists in many of them. That bias can create a situation where someone can choose to be Agile or choose to comply with corporate policy. That’s a devil’s choice.
For example, we have a governance point that is used throughout all levels of the IT organization called “Baseline” where all design and specification (and estimation) is done, and signed off. This is supposed to occur before software is delivered. Does that favor waterfall? You betcha. This governance point is mentioned in one of the metrics all the way up to the CIO scorecard! BDUF is built in to the DNA itself.
But if you look at the reasons that people give for requesting BDUF (Big Design Up Front), it goes like this: you can reduce risks by requiring that everyone understands and agrees with the requirements, features, scope, timelines, responsibilities, deployment model, etc…
Right. Pigs fly.
I do see the intent, and it is honorable. Reducing risk is a good thing and we want to increase the number of systems that are delivered on time and on budget with fewer defects. But I think that Agile methods have proven that there is another way to accomplish the goal of “improved delivery.” Unfortunately, they do not fit into the same neat little box.
Where waterfall requires 600 pages of documentation to be written up front, Agile requires that most of those pages are never written. It is not correct that Agile methods produce design documents “as you go.” That is nonsense. Agile methods produce 10 pages of diagrams, and nearly no accompanying text.
So is architecture a BDUF process?
Some of it is. If you follow the RM-ODP model or 4+1 views, you are going to be tempted to over-specify and over-architect. After all, the 4+1 views present a mechanism for creating a “complete” model of a software system. That’s great, if you want to create a complete model of a software system. But why would you want one? Why would it be a goal to have a complete description of a software system outside the software itself? Would a “partial” description serve the needs more effectively?
BDUF architecture is rarely a good thing.
Agile architecture, however, is often a good thing. Agile architecture is the act of producing enough architecture to meet the needs of the project, and nothing more, and producing it in a timely fashion, with a minimum of effort. Agile architecture RARELY produces a detailed class model in advance.
Agile architecture often produces a high-level component model and context model to establish the existence of components, their names, and perhaps even the division of responsibilities in the dev team itself. (think: Scrum of Scrums). Agile Architecture nearly never produces diagrams of technical things, like the structure of a message. Dev tools do that, from the code itself.
Agile architects will produce models using a dev environment tool, like Visual Studio or Sparx Enterprise Architect, not a diagramming tool like Visio that cannot easily be connected with the code.
Agile architects will use diagrams to communicate between people and to express artifacts into code where developers have real freedom to make the magic happen.
Agile architects will not only leverage patterns, but also complete reference models. They will consume a well-built reference model, inject the components that will be developed for the application, and get the team off on the right start. They will not “craft a new architecture” for every need, but will build-from-pre-existing-designs 80-90% of the time using frameworks that produce maintainable, secure, reliable, and easily deployed systems.
Failure to architect a system is a failure to deliver. On the other hand, hand-crafting every system is also a failure to deliver. The difference between the two, and the middle-way that defines success, is agile architecture.
