I’m going to get some heat for that title… I’m sure of it. Archimate has been a diagramming standard for some elements of Enterprise Technical Architecture for a couple of years now. However, with the new release of Archimate 3.0, this interesting visual language is now directly useful to Enterprise Architecture from the perspective of a Vanguard EA.
Organizations do not work, in real life, like they work on paper. On paper, there are departments (all shaped like a neat rectangle) and business processes with neat inflows and outflows of responsibility and information. On paper, you improve things by modeling things on paper, and then moving things around, on paper, then teaching people to follow the process that your neat paper diagrams represent.
In real life, there are human beings and the tools that they use. Sometimes the tools move information from one person to another. Sometimes, they just aid in communication. People meet and get to know other people, and they learn to trust some, and distrust others. Some folks have different measures and motivations and just “pass by” one another. Some subset of these people will have shared cultural values and expectations. There may be many cultures in an organization: both because the organization is in multiple places, and because people from multiple places join an organization. Also, “business culture” arises as leaders achieve successes and people learn to use certain “cultural expectations” to get things done efficiently.
Reality is a lot messier than pretty rectangles.
Enterprise Architects apply science and engineering and aesthetics to the challenge of organizational change. We are unique in that most other “change artists” are not focused on engineering and some even ignore science. (see Daniel Pink’s TED Talk on the Surprising Science of Motivation). Few even know how to spell aesthetics. Yet, when you are dealing with systems that contain and include people, you have to use aesthetics, and you are ill prepared for success if you ignore science. Engineering is a mindset as much as a class of methods. It involves applying the things that science has discovered and using that understanding to build great (and sometimes terrible) things. Engineers build on ideas and use them, often experimenting on systems that are too complex and intertwined for “pure science” to get arms around.
As Enterprise Architecture is such a young science, we have relied to heavily on the “boxes and lines” model of enterprises, and not enough on the messy but important sociocultural view of an enterprise. We find it easier to document, and model, and even simulate, processes as though people were interchangeable and their relationships didn’t matter.
That is just lazy.
It is time to get up off our collective butts and start working out ways to understand sociocultural influences, relationships, and architectures. We have to build ways to detect, measure, and consider these structures when we measure capabilities, or improve processes, or suggest automations, or evaluate business models, or any of the two dozen things that EA’s do.
The value of EA often comes to an executive in the form of a reasoned opinion that is based on data that no one else is looking at. Let’s consider the possibility that examining sociocultural influences can provide interesting opinions that an executive will find valuable.
We should consider sociocultural information if:
- Sociocultural influencers can impact the speed of change in an organization.
- Sociocultural connections can impact the decision making and governance processes
- Sociocultural strengths would allow rapid improvement in business capabilities needed for a shift in strategy
- Sociocultural blind spots would prevent an organization from recognizing an existential threat
Think about it. Do you believe that any of those statements are false? I can find ample examples for each one. So if sociocultural interactions matter, why are we not tracking them, learning from them, using them to make decisions?
It’s only hard because we haven’t tried.
(This post inspired by the many similar pleas shared by J.D. Beckingham in social media).
In the Open Group conference at Newport Beach, I listened to a series of presentations on business architecture. In one of them, the presenter described his practice of using Osterwalder’s Business Model Canvas to create a model of his program’s environment after a business program (aka business initiative) is started. He felt that the canvas is useful for creating a clear picture of the business impacts on a program. There are problems with this method, which I’d like to share in this post.
Let me lay out the context for the sake of this post since there is no business architecture “standard vocabulary.”
A “business program” is chartered by an “enterprise” to improve a series of “capabilities” in order to achieve a specific and measurable business “goal.” This business program has a management structure and is ultimately provided funding for a series of “projects.” The business architect involved in this program creates a “roadmap” of the projects and to rationalizes the capability improvements across those projects and between his program and other programs.
For folks who follow my discussions in the Enterprise Business Motivation Model, I use the term “initiative” in that model. I’m using the term “program” for this post because the Open Group presenter used the word “program.” Note that the presentation was made at an Open Group conference but it does NOT represent the opinion or position of the Open Group and is not part of the TOGAF or other deliverables of the Open Group.
The practice presented by this talk is troubling to me. As described, the practice that this presenter provided goes like this: Within the context of the program, the business architect would pull up a blank copy of the business model canvas and sit with his or her executive sponsor or steering committee to fill it out. By doing so, he or she would understand “the” business model that impacts the program.
During the Q&A period I asked about a scenario that I would expect to be quite commonplace: what if the initiative serves and supports multiple business models? The presenter said, in effect, “we only create one canvas.” My jaw dropped.
A screwdriver makes a lousy hammer but it can sometimes work. The wrong tool for the job doesn’t always fail, but it will fail often enough to indicate, to the wise, that a better tool should be found.
The Osterwalder’s business model canvas makes a very poor tool for capturing business forces from the perspective of a program. First off, programs are transitory, while business models are not. The notion of a business model is a mechanism for capturing how a LINE OF BUSINESS makes money independent of other concerns and other lines of business. Long before there is a program, and long after the program is over, there are business models, and the canvas is a reasonable mechanism for capturing one such model at a time. It is completely inappropriate for capturing two different models on a single canvas. Every example of a business model, as described both in Osterwalder’s book and on his web site, specifically describe a single business model within an enterprise.
I have no problem with using business models (although my canvas is different from Osterwalder’s). That said, I recommend a different practice: If the business initiative is doing work that will impact MULTIPLE business models, it is imperative that ALL of those business models are captured in their own canvas. The session speaker specifically rejected this idea. I don’t think he is a bad person. I think he has been hammering nails with a screwdriver. (He was young).
Here’s where he made his mistake:
In the oversimplified value stream model above, Contoso airlines has three business models. The business owners for these three businesses are on the left: Bradley, Janet, and Franklin. Each are primarily concerned with their own business flows. In this oversimplified situation, there are only two programs, each with one project. If the session speaker were working on the Plantheon program, his idea works. there is only one business model to create. That nail can be hammered in with a screwdriver. Lucky speaker. Showing Franklin his own business model is a good thing.
But if we are working on the Flitrack program, what do we show Franklin? if we create a “generic” canvas that includes cargo, he will not recognize the model as being applicable to his concerns. He will not benefit and neither will the program. In fact, Franklin will think us fools because he had a presentation from Plantheon yesterday showing him an accurate model… don’t you people talk?
Program Flitrack should have one-on-one conversations with Bradley and Janet to develop their business models. The business model that Franklin cares about does not need to be created again. It can come out of the repository. The Flitrack program would consider all three models as independent inputs to the business architecture of the organization impacting the program.
Anything less is business analysis, not business architecture.
A few days ago, I quickly dashed off a post on the difference between a business architect and a business analyst. The reaction was immediate and rather vociferous. The IIBA took me to task for saying that a business architect is NOT a business analyst. In addition, Tom Graves (Enterprise Architect) asked me to consider the possibility that the two roles are primarily different in another way, altogether. Tom asked me to consider the possibility that an architect role is primarily one of synthesis (putting things together), while an analyst role is one of analysis (taking things apart). I beg to differ. This post included my thoughts on that distinction.
Graves’ trilogy: Analyst-Anarchist-Architect
Tom has pointed out, in past articles, that there is real value for enterprise architects to consider the Hegelian triad of Thesis-Antithesis-Synthesis. In his post, Tom presents a triad, based on Hegelian thinking, three different roles in sequence: business analyst – business anarchist – enterprise architect.
In Tom’s thinking, the analyst is good at creating an initial hypothesis that represents incremental improvement… at doing things right. The anarchist is the role that questions the assumptions underlying the analysis. It is the role of anarchist to test those assumptions, and make sure that they do indeed align with the real world of “trial, error and experience”. The anarchist prevents us from accepting our assumptions. The architect puts it all back together. According to Tom Graves:
And the architect role is about bringing it all together again. It’s the ‘synthesis’ part of the triad; but it’s also about the Concrete, about making things real, being effective – about doing the right things right in a concrete, practical way.
Here is where I have to take my hat off to Tom. There is a very important thought process going on here, and one that I both agree with and can immediately use. I admit to not having taken the time to really grok Tom’s post prior to now, but I couldn’t agree more with the thinking process. You have to form an initial idea, then break apart the assumptions in order to test the initial idea, and lastly bring it all together in a solution that actually works. It’s an excellent approach.
Shouldn’t this kind of thinking simply be a template for each individual person? Shouldn’t one person perform all three activities? Tom addresses this as well.
One way to resolve the architecture of that architecture is to have just one person doing all of those roles – after all, they’re different roles, not necessarily different people. But that can sometimes be quite a ‘big ask’, because each of the roles does demand different skillsets, different paradigms, even different worldviews – again, somewhat tricky.
Tom suggests that it is difficult for one person to perform all three, and that large organizations (and large markets) may have the freedom to separate out the roles into different people. It’s an interesting idea, but I don’t know if provides the clarity I’m looking for.
I believe that Tom is completely right in one respect. Solving a problem effectively requires that you go through stages of thinking. If you simply look at the problem and conceive of a couple possible solutions, you could just as easily fail to consider the optimum one (not on the list), or choose the wrong solution (whatever “wrong” means). In order to reach the best possible decision, you must go through the additional steps of antithesis and synthesis. However, I don’t think that this distinction is sufficient to explain and position the roles of Business Analyst and Business Architect.
The process of thinking through a problem applies to ALL roles that solve problems (a fairly long list). It doesn’t just apply to business analysis. Following the path from thesis to antithesis to synthesis is an art practiced by artisans, craftsmen, mathematicians, scientists, engineers, leaders, managers, and politicians. It is best practice for all of human thought, and not just one area of human endeavor. Everyone who thinks, and considers, and solves, should use all three steps. To use Tom’s terminology, each person should be an analyst, an anarchist, and an architect.
Different Efforts, Different Results
Tom’s thought process is excellent, but I don’t believe it answers the core question. Over the past few years, we’ve seen the emergence of two different “job titles.” Both jobs emerged out of the need for the information technology division to address business problems in new and novel ways. The core question that I’d like to address is simple: is this something that one person does, or something that two people do? Are we more effective, and efficient, to separate the roles and responsibilities?
Some things we all agree on. The business analyst role is much more tactical than the business architecture role. Traditionally, the business analyst is required to understand the problems of a business area and to document the requirements of the business in solving them. The business analyst is NOT accountable for developing the solution, or even the vision for the solution (The solution architect does that). He or she is accountable for understanding the problem and documenting the requirements that the solution must meet.
The business architect role is a more recent innovation. This role emerged out of the need to insure that departments and divisions are using IT resources correctly by asking for the right problems to be solved. From there, the role has expanded to a non-IT-focused value proposition. The business architecture role is important. Without the business architect involved, we may do an excellent job of solving problems that the overall enterprise does not need solved, when the real enterprise-level problems are going unaddressed or under-resourced due to the long list of demands from the existing businesses.
The business architect is different from the business analyst because he or she is fundamentally charged with four different responsibilities:
- understanding the actual enterprise-level needs and the relationship between one business area in respect to the overall strategies,
- partitioning the services that one business area should produce and the needed level of maturity for those services,
- creating a vision of those services, from the perspective of the business, and
- insuring that it aligns to the actual and proposed architecture of the business as a whole.
Note that (2) occurs rarely… only when major changes to the business models themselves occur.
Some analysis will perform responsibilities (1) and skip to (3). In most cases, that works. On the other hand, performing responsibilities (2) and (4) requires the skills of an architect. There are two different skill sets here. Can one person do both? Yes. Should they? That depends.
As these roles continue to mature, we need to either carve out distinctions, or merge them into a single role.
Business Analyst and Business Architect as one person
In my prior post, I made the case that there are many differences between a business analyst and a business architect. My pr
ior post was based on the assumption that there needs to be two different people playing these roles. That assumption is NOT valid in all cases.
There are many situations where it makes a great deal of sense for the activities of business architecture and business analysis to be performed by ONE individual for financial and logistical reasons. For example, if the IT unit in question has a small set of responsibilities, or if we are talking about a medium-to-small business (or business area), there just isn’t enough work to keep two different people employed full time in complementary roles. Within my company (Microsoft), there are some smaller areas of the business that are covered by one individual who performs both business architecture and business analysis tasks.
The question that I have, however, is simple. While it is possible for one person to perform two jobs, does that mean there SHOULD be one job? Should we merge the roles so that every business analyst should be an architect, and every business architect should be an analyst?
Business Analyst and Business Architect as complementary roles
Regardless of what we want to happen, reality is going to keep getting in the way. Both roles exist. Sometimes they intersect. The real challenge comes when two people have to play complementary roles, one as a business architect, and the other as a business analyst. In larger organizations where business architects are appearing as independent roles, and in situations where consultants are being hired, this situation is increasingly common.
In order to be effective, these two folks need to have clear accountabilities. They need to be clearly supporting the success of one another, but able to succeed independently of one another (the failure of one cannot prevent the success of the other). In order to meet these criteria, there is one very important distinction. Both must have a different set of problems to solve, and both must have the full scope to solve those problems. Both must perform the three steps of emergent thought that Tom points out: thesis, antithesis, and synthesis… or analyst, anarchist, and architect.
There is no good source, in existence, for clarifying those accountabilities. The Business Analysis BOK focuses on skills and methods, not accountabilities. The Business Architecture BOK focuses on different skills and methods, but not accountabilities. Both fields seem happy to simply overlap. That is probably OK from the perspective of describing the fields.
However, in an actual organization, where people have jobs to do, more clarity is required.
No matter how we reconcile these two roles, we need to understand that the growth of business architecture will not be abated just because the profession of business analyst has laid a moral claim to the activities that business architects have decided to focus on. Rather than argue about whether business architects are, first and foremost, analysts, lets look at whether we can address two key questions:
a) Is it better or worse for these roles to be independent?
b) When both roles exist in the same organization, how do we prevent confusion, clarify accountabilities, and make both roles effective?
Arguments don’t matter. Answering these questions… that matters.
[Author’s note: within an hour of posting the following article, Kevin Brennen of the IIBA dry-roasted the post on his own blog. You can find a link to his entry here: Business Architecture is Business Analysis. I have made an attempt to fix a few of the most egregious errors in the post, and to follow up with an addendum (below).]
One distinction that I believe we should make, as the field of business architect takes hold, is the difference between a business architect and a business analyst. There are real opportunities for confusion here. In addition, there are some folks who believe that there is a good career growth path from business analyst to business architect. In this post, I will provide my opinions about the relationship.
Business Architect – A role within various types of enterprises (business, government, non-profit) that is focused on collecting information on the strategic positioning of an area of activity (line of business, business unit, department, team, etc.) and creating a clear picture of the capability gaps that may impede that area from reaching it’s full and required potential.
Business Analyst – A role either within an information technology division of an enterprise, or within a non-IT team serving as a key point of contact with an IT division. This role is focused on understanding the root cause of a specific business problem in order to develop the IT requirements needed to address that problem.
(Inevitably, someone will ask me where I got those definitions. I made them up. I reserve the right to be wrong.)
Both of these fields analyze the business… but that is where their similarities end. Let me repeat that: Business Architects analyze the business. Business analysts analyze the business.
|Business Architect||Business Analyst|
|Why||To uncover the gaps between strategic needs of a business unit, and their abilities to meet those needs, and to charter initiatives to fill those gaps.||To develop and document the detailed knowledge of a business problem that an initiative has been chartered to address.|
|How||Analysis of future-looking strategies, capturing of capabilities, and modeling of inter- and intra- business relationships needed to discover the key capability gaps that a business must be prepared to face, along with the development of cross-functional roadmaps to address them. System requirements are NOT captured.||Interviews with existing business stakeholders and SMEs to elicit business rules, understand processes, information, and systems in use, and detailing the consequences (intentional or not) of making a business change to address a specific issue. The primary result of this activity is the document of System Requirements.|
|When||Ongoing process that is triggered by periodic strategy cycles within a business||As-needed activity that is triggered AFTER a problem has been identified and requirements for a solution are needed.|
|Who||Business or IT Generalists with a strong understanding of business functional issues, interdependencies, and business structural concerns. Must be excellent at capability analysis. Must leverage modeling and rigorous analysis skills.||Business or IT Generalists with a strong understanding of information and application interdependencies, requirements analysis, and system development methodologies. Must be excellent at IT requirements elicitation. Must leverage modeling and rigorous analysis skills.|
|What||Business motivational models, Value Streams, Scenarios, Capability models, Heat Maps, Funding Maps, Risk maps||Business Requirements, Business Rules, Use Cases, and Detailed Business Process descriptions|
Perhaps this simple table will do a good job of explaining why these roles are different. If you look at the people and their skills, there is some overlap. Certainly, smart people with excellent analysis skills can do many things. But we are not talking about the people. We are talking about the actual role. There is nearly nothing about these roles that are actually the same. These are fundamentally different roles. Yes, there are people who can play both roles. (One of the software developers I hired at Acadio had a degree in archeology.)
In fact, I have never seen a business analyst successfully transition to the role of business architect. Note that this is my personal experience, and I am willing to consider that there are many folks who have made that transition. I have watched many struggle, and fail, on that road. Given what I’ve seen, I consider this a very difficult transition.
I am not going to make a lot of friends with this post. I respect that. Just sharing my opinion and my experience. Hopefully, I haven’t lost friends along the way.
[Follow-up note from Nick: I have met Kevin as well, and I respect the work that he has done, especially on the BABOK. His blog post responding to this one was not a big surprise in hindsight. However, I hadn’t expected such a complete rejection of the points. So I took a few minutes to review the BABOK v2 document. I hadn’t noticed this aspect of the guide before… guess I hadn’t been motivated enough to think about it: the BABOK defines the tasks of Business Analysis, not the role of Business Analyst.
To whit, the BABOK v2 specifically states:
“A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.”
That is a very expansive definition.
Let’s put in a terms of a metaphor. What if the role of “physician” were defined in the same way. Would it look like this?
A physician is any person who performs the activities of diagnoses, treatment, surgery, prescription, pharmaceutical distribution, wellness evaluation, or their related activities. Physicians may include not only people with the job title of physician but also registered nurse, nursing assistant, pharmacist, pharmacy technician, physical therapist, physician’s assistant, psychiatrist, psychologist, chiropractor, personal trainer, and massage therapist or any other person who performs the tasks described in the Physician’s Desk Reference.
Do you see the problem? The BABOK itself points out one of the key reasons for defining the profession: to define “the skills and knowledge that people who work with and employ business analysts should expect a skilled practitioner to demonstrate.” How can an employer expect a specific level of skill if it that bar is so low that a dozen different roles are expected to perform it well?
This is a problem with the BABOK, not the analysts themselves. Including such a wide array of roles in the “definition” of a business analyst creates a situation where no other profession can define a role that cares about similar concerns without overlapping with this definition. According to this definition, I’ve been a business analyst for 20 years. In fact, I stopped playing the role of business analyst over a decade ago.
Here’s a simple test to see if you are a Business Analyst or something else: if your employer decides to completely erase his IT budget, and spend NOTHING NEW on IT systems, how busy would you be? If you answer “I’d go to part time” then you are sitting squarely on the line between business analyst and some other role. If you answered “I’m out of work,” then you are a full time business analyst.]
I’ve been looking at different ways to implement the ATAM method these past few weeks. Why? Because I’m looking at different ways to evaluate software architecture and I’m a fan of the ATAM method pioneered at the Software Engineering Institute at Carnegie Mellon University. Along the way, I’ve realized that there is a flaw that seems difficult to address.
Different lists of criteria
The ATAM method is not a difficult thing to understand. At it’s core, it is quite simple: create a list of “quality attributes” and sort them into order, highest to lowest, for the priority that the business wants. Get the business stakeholders to sign off. Then evaluate the ability of the architecture to perform according to that priority. An architecture that places a high priority on Throughput and a low priority on Robustness may look quite different from an architecture that places a high priority on Robustness and a low priority on Throughput.
So where do we get these lists of attributes?
A couple of years ago, my colleague Gabriel Morgan posted a good article on his blog called “Implementing System Quality Attributes.” I’ve referred to it from time to time myself, just to get remind myself of a good core set of System Quality Attributes that we could use for evaluating system-level architecture as is required by the ATAM method. Gabriel got his list of attributes from “Software Requirements” by Karl Wiegers.
Of course, there are other possible lists of attributes. The ISO defined a set of system quality attributes in the standard ISO 25010 and ISO 25012. They use different terms. Instead of System Quality Attributes, there are three high level “quality models” each of which present “quality characteristics.” For each quality characteristic, there are different quality metrics.
Both the list of attributes from Wiegers, and the list of “quality characteristics” from the ISO are missing a key point… “Time to release” (or time to market).
The missing criteria
One of the old sayings from the early days of Microsoft is: “Ship date is a feature of the product.” The intent of this statement is fairly simple: you can only fit a certain number of features into a product in a specific period of time. If your time is shorter, the number of features is shorter.
I’d like to suggest that the need to ship your software on a schedule may be more important than some of the quality attributes as well. In other words, “time-to-release” needs to be on the list of system quality attributes, prioritized with the other attributes.
How is that quality?
I kind of expect to get flamed for making the suggestion that “time to release” should be on the list, prioritized with the likes of reliability, reusability, portability, and security. After all, shouldn’t we measure the quality of the product independently of the date on which it ships?
In a perfect world, perhaps. But look at the method that ATAM proposes. The method suggests that we should created a stack-ranked list of quality attributes and get the business to sign off. In other words, the business has to decide whether “Flexibility” is more, or less, important than “Maintainability.” Try explaining the difference to your business customer! I can’t.
However, if we create a list of attributes and put “Time to Release” on the list, we are empowering the development team in a critical way. We are empowering them to MISS their deadlines of there is a quality attribute that is higher on the list that needs attention.
For example: let’s say that your business wants you to implement an eCommerce solution. In eCommerce, security is very important. Not only can the credit card companies shut you down if you don’t meet strict PCI compliance requirements, but your reputation can be torpedoed if a hacker gets access to your customer’s credit card data and uses that information for identity theft. Security matters. In fact, I’d say that security matters more than “going live” does.
So your priority may be, in this example:
- Testability, and
This means that the business is saying something very specific: “if you cannot get security or usability right, we’d rather you delay the release than ship something that is not secure or not usable. On the other hand, if the code is not particularly maintainable, we will ship anyway.”
Now, that’s something I can sink my teeth into. Basically, the “Time to Release” attribute is a dividing line. Everything above the line is critical to quality. Everything below the line is good practice.
As an architect sitting in the “reviewer’s chair,” I cannot imagine a more important dividing line than this one. Not only can I tell if an architecture is any good based on the criteria that rises “above” the line, but I can also argue that the business is taking an unacceptable sacrifice for any attribute that actually falls “below” the line.
So, when you are considering the different ways to stack-rank the quality attributes, consider adding the attribute of “time to release” into the list. It may offer insight into the mind, and expectations, of your customer and improve your odds of success.
I am currently noodling the idea of a one-page view of my employer (Microsoft) for the purpose of rationalizing the sharing of services across business units and business models. (If you understood the previous sentence, you are probably an enterprise architect, even if that is Not your title).
As a result, I’m on a hunt for the various one-page views that other companies have produced. The excellent book “Enterprise Architecture As Strategy” (Ross and Weill) provides three tangible examples (Delta Airlines, ING-Direct, and MetLife). A fourth I found entirely by accident this morning… a very old one drawn by a Disney cartoonist in 1957, and made available here: (http://taotwit.posterous.com/the-visualisation-of-business-models-did-disn).
This is an interesting view in that it illustrates the relationships between the business units and how they functionally support one another. It doesn’t allocate responsibility, but rather demonstrates responsibilities through the relationships. In effect, it is a somewhat “contractual” view, indicating the accountabilities between business units. Fascinating for many things, one of which is the date.
The synchronicity of this find is resonating for me because yesterday, a friend and fellow Enterprise Architect within Microsoft named Krishna Srinivasan, shared a very similar view that demonstrated how the functional units of Microsoft could be viewed. I’m sharing it here because, honestly, the view was so generic that it is difficult to view it as “revealing” anything that someone couldn’t guess. That said, it is a fascinating, modern depiction of many of the same key concerns that the 1957 view of The Disney Company was trying to illustrate. One key distinction: in stead of communicating relationships in terms of accountabilities, it demonstrates process relationships (inputs and outputs).
One bit of brilliance to consider is that you can track the various processes in the company by following the arrows from box to box to box. It doesn’t quite meet the needs I’m looking for in shared service rationalization, but it does say a lot about how organizations can be represented visually.
A co-worker and I spent an hour doing something innovative… and no, it was not part of a “Google 20% strategy.” We spent an hour discussing PKI, personal identity, and trust of both “passive content” (like documents) and “active content” (like applications) as that content originates from one actor, passes through another actor, and finds its way to a device that I own. We spent a lot of time thinking through, and discussing, some fascinating ideas and thinking about how we use notions of “trust” and how those notions have to change as our world becomes increasingly digital, interconnected, and fragile.
The point of this post is this: that was perhaps the most fun, interesting, and thought provoking conversation I will have this week. In many ways, it may end up being the most valuable (assuming I decide to draw value from it). And the entire conversation started with a question, or a series of questions, that my co-worker had on information security and content assurance.
The power of a question…
I’m working on a book with a friend of mine. He’s excellent at thinking through ideas, and bringing them to the fore. He’s an amazing speaker and an effective strategist and leader. A writer… not so much. One tactic that we are pursuing right now is the notion of a conversation. If I can send him a series of questions, can he make a recording of his answers and send them back to me, and allow me to author a chapter for him. We are looking at that idea right now. It may not work. If it does work at all, it will be because of the “power of a question” led to thinking along the lines of a specific topic… thinking that can be distilled into a simple, logical, consumable form.
How many questions do you answer every day? If you are in the EA or IT architecture fields, as I suspect many readers of my blog are, you probably answer a sizeable number. Architects are often employed to “find the answers.” But let’s not be too sure of ourselves. Perhaps the real power of the work we do is not in the answers we give, but in the questions we ask.
For each question we ask has the potential to stimulate thought, to trigger ideas, and perhaps to develop an innovative idea. If someone asks me a question, and I ask ten people various questions as a result, and they each ask ten people, then 111 people were impacted by a single question. As long as there is a way for innovation to work its way through that community, then we have the opportunity for one question to trigger thinking in over 100 people, potentially leading to a useful and practical innovation.
All because of the power of a question.
One of the most common, and reasonable, mechanisms for achieving clarity on the roadmap for a single platform is “demand management.” It is also one of the areas of IT that is both rapidly evolving and poorly defined. I’d like to offer an opinion about what demand management is, and is not, and how it meets some, but not all, of the planning and governance needs of IT.
Caveat Emptor: In the post below, I’m sharing my opinion, which will probably differ from yours. I ask that you follow along with an open mind, and consider the possibility that we may be using the same words in different ways, before pointing out how “wrong” my thinking is. That said, I would love to hear feedback from others, and to improve my own thinking in this space. Please share your thoughts.
Assertion 1: IT Demand Management is poorly defined.
In the book “IT Success: Towards a New Model for Information Technology” author Michael Gentile provides a reasonable description of demand management… or at least he starts to.
Using the fundamental premise that not all demand from the business will be approved—because of business priorities on the one hand, and IT resource and scheduling constraints on the other—the best way of representing demand would be via a funnel. Demand from the business enters at the top, follows one or more decision-making processes, and then either exits at the bottom as approved work to be executed, or remains in the pipeline pending further evaluation. – Michael Gentile, “IT Success: Towards a New Model for Information Technology” as excerpted in CIO magazine (link)
This is a reasonable explanation of what demand management is. As a more formal definition, IT Demand Management is the practice of collecting together all of the demands that will be fulfilled by a particular IT group, team, or organization, and balancing all of those demands with the limited supply of resources in order to produce an ordered list of activities, on a specific timeline, for that group, team, or organization to fulfill.
Assertion 2: Demand management does not deliver alignment
Unfortunately, if the article in CIO that I cite above is any reflection on Mr. Gentile’s book, he goes wildly off the rails, describing demand management as the process by which IT achieves alignment and delivers value. That is an interesting notion but it is fairly easy to disprove.
What proof do I offer? A counter-example. Microsoft IT has been performing the kind of demand management that Mr. Gentile describes for well over a decade. At no time did demand management deliver alignment. When alignment was achieved, it was achieved in spite of, or regardless of, the maturity of the demand management process, and not because of it.
Alignment happens when a team or group of people decides to build the right solution, instead of building the solution right. But more importantly, alignment occurs when a team decides NOT to build something, or to build something less than was requested, or in a different order than requested, because it meant that the business was more able to deliver on strategic goals.
Mr. Gentile and I agree on this understanding of alignment. We disagree that demand management gets you there.
Assertion 3: Alignment processes occur BEFORE demand management processes
Starting with demand is important and useful… if you already have a solution, and that solution has demand. Once you have a solution, you have to manage the demand against that solution. You don’t have infinite resources. So if there are four teams within your company that want to use your public website to meet their goals (let’s say lead generation, ecommerce, customer support, and investor relations) but only one team that can manage the public website, then you will need to use demand management. You need to collect the requirements from different teams, go through a rational and mature process for prioritizing those requirements, create a roadmap showing which requirements to meet in which order, communicate that roadmap, and track to it. That is demand management.
However, if you THINK you need a solution to a problem, and you are a business leader, your request could go into a demand management “funnel” and come out the other end producing a solution to a problem that you did not have. That is misalignment, and demand management will do little or nothing to prevent it.
Alignment requires a different process, one that examines the goals of the business, rationalizes them, finds common impact areas, and FRAMES THE DEMAND. Alignment decides what demand is rational. Alignment occurs BEFORE the demand management process does. To accept all demand against IT without performing alignment activities first is an anti-pattern. Demand management practices lend an air of “officialness” to the resulting roadmap, and once that roadmap is produced, it is very difficult to come back to the project teams and point out that the hard-won priorities don’t align to business strategy!
Discussion and Conclusion
These are tough assertions for many IT folks. This is one of the major reasons, in my opinion, that Enterprise Architecture is often unwelcome within IT, but well received outside of IT… because Enterprise Architecture attempts to achieve alignment in spite of the often well established practices of IT demand management. Without clear understanding of the dependency that demand management SHOULD take on alignment, the processes will conflict. Demand management will produce a list of things to do, and alignment will produce a different list. The only way to reconcile this is to perform alignment activities first, and then demand management activities, to produce the ultimate roadmaps.
That is my perception, anyway. I know that some folks will assert that demand management is a larger process, and it includes the “alignment” activities that I speak of. That may be an interesting matter of semantics. However, if this were true, then the “funnel” metaphor breaks down, because any demand management process that includes alignment activities would not resemble a funnel. In a funnel, all of the stuff goes in the top and the stuff coming out of the bottom is a direct reflection of what went in the top. Alignment assumes that most of the stuff going in the top is wrong, and that a lot of stuff is missing.
The “funnel” metaphor for demand management is accurate, as long as demand management doesn’t deliver alignment… and it doesn’t.
In the past, I’ve been guilty of this sin: gold-plating. Back when I was a solution architect, I would (often) think about the things that the business is going to need, but never asked for. I would occasionally include elements in the design to support those needs, even though the business didn’t ask for them. Here’s the sad thing: I considered it to be a good practice.
I was wrong.
Let’s pick a situation that most folks understand: e-commerce. If you visit an e-commerce site and you buy something, you (the customer) will want to be able to track and cancel that order. One common additional feature is the ability to track the shipment itself (through UPS, Fedex, or DHL).
You are building a brand new e-commerce system. Let’s say that the business requirements ask for a set of pages for a shopper to view and cancel their orders. But there is no requirement for tracking the shipment.
Still, you know that someone will ask for it someday, so you build in some features to allow the shipment to be tracked. Perhaps you hold on to the tracking company id, the tracking number, a URL for tracking, and some logic to pull it all together. You even build a generalized “tracking API” so that a REST client can track the shipment in a mashup. How cool is that!
That would be gold plating.
Is it a sin? Is this good or bad? (more…)