Level: Introductory Editorial staff (dwinfo@us.ibm.com), developerWorks, IBM
20 Dec 2005 In this monthly column, IBM visionaries provide their insight and outlook about issues facing IT architects today and in the future. This month they consider the question, "How do I translate the business needs of my organization to IT requirements so that they can be addressed within my system architecture?"
Introduction
Note: For a general introduction to the Insight and outlook column, please see the first installment.
As an IT architect, you probably often find yourself sitting between a rock and a hard place, the rock being your business's goals, the hard place being your IT system. Both are big, hard to move, inflexible. Those who develop one don't necessarily understand the other. It seems that business people express themselves using one language, while technical requirements are written in another.
That's where you arrive to save the day: to understand both and perform the necessary translation so that IT reflects the needs of the business and, sometimes, business goals change to encompass the abilities of IT. Not an easy job, but that's why you earn the big bucks. [grin]
Because this part of your work can be difficult and painful, we turned to our IBM panel of architecture experts to seek their guidance. This month, we asked them to share their methods for expressing the needs of business in crisp technical requirements that can be successfully implemented by the IT team.
What we offer here cannot be viewed as comprehensive. Entire volumes have been written on translating business needs into technical requirements, and more could be written without exhausting the topic. Each IT architect's interest in receiving an answer to this question is at least slightly unique, and no single answer can satisfy everyone. Nonetheless, our experts point you toward useful, thought-provoking directions that we believe can help you find the most appropriate answer to this month's question.
Thanks again to Holt Adams, our contributing editor, whose discussion of this month's issue you can read below.
Keep checking the developerWorks IT architecture pages every month: The topic of how to translate business needs into IT requirements will be an ongoing area of focus.
We also welcome your ideas about the future direction of this column. Is there a question you need answered by our team of experts? Post your question to our IT architecture discussion forum. Or send me a note at pdreyfus@us.ibm.com.
Paul Dreyfus, Editor
developerWorks SOA and Web services
pdreyfus@us.ibm.com
p.s. To show no favoritism and let the conversation unfold unfettered, we order our contributors' answers alphabetically, this time in reverse order. (Readers paying close attention noticed that the first column's contributors are ordered from A to Z.)
One word: use cases (OK, two words)
To quote from the movie The Graduate, I just want to say one word to you: use cases. (OK, that's two words.) For years we've employed use cases to model applications. Now, with Service-Oriented Architecture (SOA), we're using them to model businesses as well.
In his book, Writing Effective Use Cases, Alistair Cockburn defines a use case as "a contract between the stakeholders of a system about its behavior." The use case must fit within the scope of the system being defined, represent the point of view of the primary actor using the system in this case, and express the actor's use of the system at a consistent level of abstraction.
For example, one use case for a stock trading Web site is "purchase stock," which enables a customer to use the site to buy shares. The use case describes what the customer does and how the site reacts, ignoring for now how the site will actually implement the behavior.
 |
In a business use case, the actor is a stakeholder and the system is the business itself.
-- Bobby Woolf
|
|
Use cases can be used to model services; I call these service use cases. When a use case describes a service, the actor is the service consumer and the system is the service provider. As with any use case, the focus is on what behavior the service provider supplies, not how it implements the behavior. (See my developerWorks article, "Streamline SOA development using service mocks," for more about service use cases.)
Use cases can also be used to model your business. In a business use case, the actor is a stakeholder -- a user of the business (such as a customer or employee, even a shareholder or government regulator) -- and the system is the business itself, the company that produces products and sells them to customers. What does your business do? What do customers want it to do; what are they willing to pay for? What do employees need it to do so they can do their jobs? And bottom line: How do these stakeholders interact with the company? Those are business use cases.
Once you have business use cases, you can then link them together to make business processes -- procedures the company can perform. These processes are themselves business use cases, and complex business use cases can be realized as business processes. Simply put, these processes show what the company does and how it does what it does. And the processes and the steps in each process, as described earlier, model services.
Once you've used use cases to model your company (or some part of it) as business processes composed of services, the goal is then to start automating as many processes and services as possible. (The ones that can't be automated are human tasks.) The applications that implement this automation (which implements processes and services) are applications with a Service-Oriented Architecture. Now you're doing SOA.
Document the process
When I sit down with a client to discuss a new program or development effort, I immediately look to see whether the business stakeholders are either present or represented in the room. Subsequently, I look for well-documented business processes and data requirements. Unless the effort is a "green-pasture" (that is, it has never been done before), there must be a good understanding of the as-is and to-be business processes supported by the new application or functionality. Either way, if the client does not understand the business, there is little chance the architect can effectively define the system requirements.
I personally advocate the development of business scenarios to document business processes. A business scenario allows you to identify system requirements in the context of the overall business problem. The Open Group has an excellent booklet about understanding and developing business scenarios, titled Manager's Guide to Business Scenarios.
|
If the client does not understand the business, there is little chance the architect can effectively define the system requirements.
-- Andras Szakal |
|
After the to-be business requirements are identified, it's beneficial to maintain a list of functional and nonfunctional line-item requirements. You could use spreadsheets to maintain this list, but if you're trying to maintain tractability to requirements or manage requirements according to priority or category, it's an inferior method. I'm a big proponent of using tooling to manage requirements; for this, I suggest using IBM Rational® RequisitePro®.
With the initial set of requirements identified from the business scenarios, we can begin the process of defining system behavior. You can accomplish this by leading a
Joint
application development (JAD) session to flesh out the behavior of the to-be system, according to the initial line-item requirements. With a JAD session, the architect can work with stakeholders to identify the desired system behavior from which use cases and scenarios can be documented. Refinements to the use cases and scenarios help define the final list of functional and nonfunctional line-item requirements.
Use RequisitePro from the start
Rational RequisitePro is an under-appreciated Rational product used to gather, document, and refine requirements and other business concepts. It lets business users write statements in Word documents, then capture them in a database and associate the statements with additional user-defined attributes. The statements can describe requirements, policies, user roles, stakeholders, and anything else relevant to a business.
When using an iterative requirements refinement process, you can link related statements. For example, a requirement such as "The portlet displays X, Y, and Z customer information" can be linked to another requirement such as "Roles A, B, and C should receive all necessary customer information." In this case, the first requirement is a refinement of the second. This models the relationship between the general requirement and the detailed requirement.
|
"When I change this business requirement, what aspects of the model or implementation must change to match?"
-- Mark Linehan
|
|
In my mind, you use RequisitePro at the front end of the model phase. The statements managed in RequisitePro become input to a modeling tool such as
IBM WebSphere® Business Integration Modeler, Rational Sofware Architect (RSA), or Rational Software Modeler (RSM). In fact, Rational Sofware Architect and Rational Software Modeler provide the ability to link RequisitePro requirements explicitly to use cases and other modeling elements. You can also link the requirements to Java™; Java 2 Platform, Enterprise Edition (J2EE); and other similar implementation artifacts. This capability lets you understand the answer to questions such as, "When I change this business requirement, what aspects of the model or implementation must change to match?"
Finally, after reading what Simon Johnston had to say, I would like to add the following:
I've recently led efforts to understand the concept of "policy," both what it is and how it should fit into the IBM chain of tools. These efforts led to the following definitions:
- Policies are declarations intended to achieve certain business goals within some business domain. This definition is consistent with the emphasis on business intent in your note and others in this thread.
- Declarations are statements in some human language. So policies fit well with RequisitePro; in a sense, policies are one kind of requirements.
Policies get developed through a refinement process starting with high-level policy declarations that typically cannot be implemented directly; these high-level declarations are iteratively elaborated upon into more detailed policies. Fully detailed policies can then be linked to implementation efforts using the RequisitePro features I described earlier. The "continuum" Simon talks about sounds consistent with this view of policy life cycle.
Calvin Powers has done an excellent Web-based presentation and demo of how RequisitePro can be used to capture and refine business policies. Visit the IBM Business and Technology Solutions Resource Library and look for "Policy Provisioning using IBM Rational RequisitePro and IBM Workplace Business Controls and Reporting" in the Demos section.
The right solution for the right capability
I like Kerrie Holley's restatement of this month's question: "How do I move from business intent to realized value or IT solution?" One of the most important things to consider when developing and architecting solutions is the corresponding level of capability and capacity required. If all I'm trying to do is publish pricing information to the Web, I could go to the closest elementary school and get someone to write HTML. However, if I'm Wal-Mart, and I'm trying to extend my supply chain across international boundaries, multilingually, and ensure that it's accessible 24x7, my capability and capacity have to be more robust.
Seasoned practitioners can help the customer move from business requirement to business intent. Business intent is more nebulous, but more closely aligned to the "bottom line" and "return on investment." Once business intent is determined, realized value is attainable through innovative and repeatable IT solutions.
Like Kerrie, I believe that business needs and IT capability overlap. This ambiguity is what makes architecture such a difficult and time-consuming process. Whether it's waterfall or iterative (we like iterative), the planning and requirement phases are always tedious. Customers rarely know what they need (although many know what they want). It is incumbent upon seasoned practitioners to help customers translate business needs into IT capability.
|
If all I'm trying to do is publish pricing information to the Web, I could go to the closest elementary school and get someone to write HTML. However, if I'm trying to extend my supply chain across international boundaries, multilingually, and ensure that it's accessible 24x7, my capability and capacity have to be more robust.
-- Calvin Lawrence |
|
This can't be done by nice, fancy tools and methodologies alone, because every project is different. Methods and techniques are meant to be guided approaches, and tools are meant to help automate those approaches. Although many projects share commonalities, seldom do they mirror one another. To assume they do is to assume that two distinct businesses, although similar, mirror each other. I've worked a lot with both Home Depot and Lowe's in the past. Although similar, they would both tell you that their businesses are different. And they both consider those differences to be their competitive edge and advantage. Many times the effects of culture, locality, and geography on business needs dictate the IT solutions being proposed. Government laws and standards can force a practitioner to architect solutions differently for the same business need based on where that solution will be deployed.
The techniques for capturing and delivering the artifacts -- use cases, scenario documents, Rational Unified Process (RUP) -- should be consistent among participating consumers. These artifacts will serve you well when, in the middle of the project, the customer changes his or her mind (business need) and decides, for example, that the system doesn't need to be up 24x7, but instead, 8x7 because they don't want to incur the cost of the 24x7 solution.
Pattern Solutions to capture best practices
When I read this question, my first thought was that I was not qualified to answer because I am not a client-facing architect. However, I do work with customers on a consulting basis. The techniques I use are not based on any formal methodologies, but rather based on a deep knowledge of the technologies and products. I agree with Holt Adams when he says "Making the magical transition from requirements to choosing technologies or products to use in constructing a solution can be a challenge." But help is on the way.
My team and I have been working on technology to link design patterns together that we call Pattern Solutions. The idea is to capture best practices to recurring problems using the comprehensive pattern frameworks in
Rational Software Architect. This approach enables us to more effectively translate requirements into technologies in a repeatable fashion. Our goal is to build a community around reusable patterns. We are envisioning an Amazon.com-like community where folks can review and vote for their favorite patterns. Tell us what you think of the idea and our implementation using the Pattern Solutions discussion forum.
Needed: common terminology
I would also agree with Kerrie's characterization of the real purpose of the translation stated in the original question ("How do I move from business intent to realized value or IT solution?"): Its purpose is the realization of value to the business from IT providing capabilities to support the intent of the business. Let's look at this concept piece by piece.
First, we have to focus on business value. The purpose of IT is not to continually update our skills with a revolving door of new technology but to contribute to the value of the business.
Another important aspect of this statement is that IT is not in the business of developing monolithic applications anymore. Instead, we provide discrete capabilities that are orchestrated in the realization of business processes. One of the promises of SOA is that it will give us the ability to provide a common vocabulary shared between the business and the IT organizations -- where business processes are implemented using services.
Finally, we get to the interesting term Kerrie used; that is, business intent. Note that he doesn't say requirements or needs or use cases. The business has an intent. Certainly use cases or WebSphere Business Integration Modeler models can help in understanding the current situation and articulating this intent. But such tools run the risk of prematurely expressing the problem in terms of the modeler's assumptions of a solution.
|
The purpose of IT is not to continually update our skills with a revolving door of new technology but to contribute to the value of the business.
-- Simon Johnston
|
|
Some time ago, there was an internal discussion in Rational management about describing a continuum for requirements, reaching from those that describe business strategy down to the actions of people or computer systems in performing tasks. This continuum included vision statements, business goals, key performance indicators (KPIs), business process descriptions/business use cases (using these interchangably), nonfunctional requirements, and the like. This discussion was long and painful, not necessarily because there was any disagreement about the concepts but because we had so many problems with terminology -- what to call these "things."
Even if we'd succeeded in our requirements continuum exercise, I agree with Kerrie that thinking in terms of tools to solve this problem is a fallacy. The continuum is not intended to say that we have to have a single tool for requirements or that there is a single method for describing transformations between kinds of requirements. However, we do need a common approach according to which all of these "things" can be managed. And we need a global view that can provide insight into the decisions and assumptions made during the transformation itself, from one level of requirements to the next.
Another concern is related to terminology but pertains more to a gap in abstraction between statements made at the business and IT levels. It is common for a business user, for example, to state a requirement for a particular task -- that it needs to be "secure." But what does that mean to the architect? Our helpful IT architect asks whether this means the task must be performed confidentially, must be tamper-proof, or requires strong encryption or something more temporary. The business users' eyes glaze over for a moment, and they stammer out "aa-a-all of it." We then have the conversation about the cost of infrastructure to support all of this security to simply deliver a simple piece of data from one service to another in a known and explicit trust boundary and after the ah-ha! moment, the business user states that what they need is the assurance that no unauthorized user gets to see data they shouldn't. So, when we look into the specification of requirements from business users, we cannot chastize them for not understanding technology. Instead, we need to have mechanisms for translating those statements of intent into sets of specific requirements at the IT level.
Right now this means that we do need to make more of RequisitePro, and Mark is correct in saying that its use needs to come up front. Not only do we need to be able to capture business intent in RequisitePro, but we must also take advantage of the linkages between RequisitePro and Rational Software Architect to trace models back to business intent. Unfortunately, there's a gap in this message because WebSphere Business Integration Modeler is not yet integrated with RequisitePro. This can be worked around by opening the WebSphere Business Integration Modeler model in Rational Software Architect and linking the Rational Software Architect view of the business model with RequisitePro.
Recently, I made a change to the Rational business-driven development proof of technology to make exactly this point: RequisitePro needs to be introduced as early as possible in the process, to capture the true intent (the problem, if you will) before any models -- either business or IT -- are developed to describe a solution. Don describes how requirements and design models can often be seen as more of a hindrance to a project than a value. In my mind, a set of requirements statements and beautiful models are still second-class artifacts -- and possibly a hindrance -- if they are not linked together.
It is this set of artifacts, linked and managed in RequisitePro, which allows the development team to understand where they are in the project and enables project portfolio management decisions to be made as a part of an overall IT governance process.
Managing uncertainty and volatility
I agree with Don Ferguson's comments and thoughts and will try to add to the dialog without repeating anything that he has already stated so well. There is also an article from the November 2005 CIO magazine, "Fixing the Requirements Mess," that also addresses the issue of translating business needs into IT requirements. I hope to avoid repeating that information, as well.
Another way to state this month's question is: "How do I move from business intent to realized value or IT solutions?"
Business needs and IT requirements substantially overlap; that is, to some people, business needs means "What is my changed or new business process?" To others, it means "How do I achieve a set of business goals with corresponding critical success factors?" To still others, it may simply mean providing a set of business stakeholders with new capabilities, such as new devices or a new screen, or simply new automated business-rule enforcement.
|
Because it is a human problem, the challenge of translating the business needs of an organization to IT requirements cannot be solved solely with tooling or methods.
-- Kerrie Holley
|
|
The very fact that the question rests on the term IT requirements surfaces an issue: Is there a difference between business and IT requirements? This can lead to a long discussion, but my point is that the lack of terminology, the lack of a common language to even discuss the problem, is itself a problem.
Our challenge is that business needs and requirements are often only partially understood and often volatile. Many development methods attempt to accommodate this uncertainty and volatility by introducing iterative development, tools, and other techniques. But these approaches only partially address the problem, because this uncertainty and volatility is only part of the problem. A requirements process must understand the type of project that is emerging before assuming that a specific approach is the optimized approach.
Project types vary because of size, scope, organization concerns, culture, knowledge of solution, current environment, and other factors. The varying types of projects require that we approach the problem of translating needs of an organization to IT requirements differently for each project. Distinctions in types of projects calls for differences in the development approach, tools, and how requirements should be managed.
Because it is a human problem, the challenge of translating the business needs of an organization to IT requirements cannot be solved solely with tooling or methods. It is a fallacy to think we can completely fix this by improving the tooling or creating a new development process, method, or technique.
Managing the requirements process for many projects requires that we have an approach for deciding what should be included in software and what should not. This process requires a combination of collaboration skills, facilitation skills, tools, techniques, and methods.
The seasoned practitioner knows that translating the business needs of an organization to IT requirements must accommodate a variety of factors. These factors include the following:
- How much is known about the business needs?
- What is known about IT requirements?
- What is the ultimate solution supposed to look like?
These factors shift constantly over the course of a project.
This is one of many reasons why practitioners who apply agile methods, IBM Global Services (GS) method, Rational Unified Process (RUP), or some other process cannot blindly assume the process to be the correct approach. There is no "one size fits all"; these are tools. The knowledgeable practitioner must pick and choose when and how to use the right tool, and match them to the types of projects and scenarios being developed.
GS method, for example, does a good job at helping by clearly stating some clear buckets (such as system context, use cases, nfrs, security) that must be accommodated by requirements. This approach helps to establish taxonomy so that when we say IT requirements we know what that means; when we say business needs, we know what we mean.
An IBM colleague of mine, John Cameron, touched upon some of these items in an internal article classifying the uncertainty we often start with when launching a project. His point is that the degree of this uncertainty, coupled with how much we know about the solution, plays a big role in how we translate the needs of an organization to IT requirements. John's analysis is depicted in Figure 1, a simple matrix used to classify projects by how much we know of the requirements and how much of the solution.
Figure 1. Classification of uncertainty by John Cameron
"Outside-in" design
 This is a good question; I wish I had a good answer. I think the most important technique for solving this problem is patience during the development process and development discipline.
Many projects do not give front-end requirements documentation and analysis and business modeling the time they deserve. Sometimes there seems to be an unstated assumption that this is "not productive coding." Formal, first-class treatment of requirements, process modeling, and artifact modeling can be time-consuming, but can also ensure that the output of the development process matches the business requirements. Requirements documentation and modeling should define test cases for the output of the development effort. If the team cannot transform requirements into test cases, the team does not understand the requirements.
Development also needs to be iterative. We have learned from Eclipse development and other projects that our development efforts need to produce a usable interim release every four to six weeks. The release should be available to the business stakeholders for use and validation that the project meets business needs. Each interim release phase should start with an agreed set of requirements and use cases/scenarios that it will meet.
|
Requirements documentation and modeling should define test cases for the output of the development effort. If the team cannot transform requirements into test cases, the team does not understand the requirements.
-- Don Ferguson
|
|
Finally, we have started to pilot a concept of "outside-in design" in the IBM Software Group. In this approach, we rely on the following principles:
- Conduct formal user modeling, including roles and user conceptual objects
- Define a set of use cases for roles interacting with the conceptual objects
- Provide low- and high-fidelity visual mock ups of the use cases/scenarios (Sometimes these are as simple as paper and pencil drawings. This allows the users of the solution to provide early assessment and feedback.)
- Build interim releases
This process is not a waterfall process and is iterative. (This approach helps provide continuous refinement of a project to ensure that it evolves in a direction of increasing satisfaction of business requirements and needs.)
Iterate and increment with a few drops of alchemy and art
 This is the Holy Grail for most business and IT professionals. Over the years, various methodologies, technologies, tools, and techniques have claimed "Eureka!" -- only to be eventually marginalized and shuffled through information technology's dispassionate, revolving door. But, our undying intellectual quest will make us revisit the alchemist's bench and try a different formula, perhaps brainstorm outside the box … hmm, while at it, maybe give a shot at proving the P=?NP problem!
Since there are no indisputable answers to this question, here are few of my observations that sketch the issues in translating stakeholder needs to IT solutions:
Lack of consistent and coherent terminology to establish common context
Typically, the vernacular of business executives is very different from that of IT architects. The business analysts/consultants try to bridge this gap, but they typically tangle (and mangle) it further by adding their own niche business domain terms and interpretation. To add to this, due to the fluidity of jobs and roles in recent years, most carry terminology context and baggage from their prior roles. I see terminology confusion regularly at customer meetings and requirement workshops.
So, one of the key needs is to establish clear, consistent, coherent, and crisp (my 4 Cs) definitions and semantics for all the terms -- nouns, verbs, adjectives, adverbs, etc. -- used in the solution's business and technology context. This establishes a foundation for an effective dialog between the executives, analysts, and architects. Yes, there are collaborative initiatives across industry sectors -- both horizontal and vertical -- to standardize terms and schemas, but these are mostly during early stages. My advice to an architect is this: Don't assume the meaning of a term, and don't hesitate to raise your hand and ask for clarification.
Inefficiency (or inability) when switching to the optimal technical perspective
This can be simply described as the hammer-nail syndrome. That is, if you are a hammer, everything looks like a nail. The human element is the prevalent force here -- it stems from our years of cognitive conditioning, our learned patterns for problem analysis and synthesis, and finally, our comfort technical zones (usually, where we have the most expertise).
To exemplify this issue: Data-centric architects view the world of requirements as entities and relationships. State machine-centric architects visualize a series of states, transitions, and actions. Process-centric architects weave requirements into orchestrated tasks and activities. Object-centric architects draw polymorphic classes, interfaces, and their relationships. Nowadays, we have service-centric architects who perceive the requirements universe as a jigsaw of composed services. And so on. Each perspective has its pros and cons, and it is important for an architect to apply the right perspective to each discrete business requirement or feature. Obviously, the decision about which is the "right" perspective can be viewed as subjective and can lead to philosophical debates. However, applying the correct approach can lead to the most effective, most elegant, and most satisfactory realization of the requirement. Switching perspectives is somewhat difficult and even the broadest subject matter expert (SME) has more than an Achilles' heel in trying to do so. Getting an SME for each perspective can make the architecture process contentious and it can create major bouts with "analysis paralysis."
Issues with requirement validation, prioritization, and traceability
It is important to review the business needs and jointly analyze with the stakeholder to synthesize the true business requirements. There are a variety of techniques (use-cases, scenarios), notations, and accompanying tools to capture the results of this work. But this area is also an art, and you gain expertise only through focused seasoning. After reviewing each requirement, it is important to share technical insight and a set of solution options (along with cost-benefit analysis) with the stakeholder. This step helps validate the requirements from a technical angle and also further aligns it with unstated business needs. While validating the options, use the discussion to prioritize the discrete requirements and establish the cross-dependencies among the requirements. These requirement dependencies help create traceability and play a significant role when change requests arrive. Again, none of this is an exact science. Tools like RequisitePro let you incorporate a requirements management template (based on RUP or any custom method), which can automate facets like traceability, transition of requirement states and artifacts, and so on.
|
Over the years, various methodologies, technologies, tools, and techniques have claimed "Eureka!" -- only to be eventually marginalized and shuffled through information technology's dispassionate, revolving door.
-- Sanjay Bose |
|
There are several other issues, such as shifting business priorities, changes in the operating climate, political and cultural barriers, skills gaps, and many more -- which can all get in the way of the solution meeting the requirements. I've coauthored an IBM Systems Journal article, "Impact of SOA on Enterprise Systems, Organizational Structures, and Individuals,†which provides insight into some of these issues.
In closing, as I shared in a recent interview with IDevNews, a good way to translate business needs to IT system architecture is to do it (borrowing approximation techniques from math) iteratively and incrementally.
All requirements are not equal
 Mature organizations understand that all requirements are not equal. Most individual requirements have no architectural implications; rather, they have implementation implications. Some requirements are vastly more important than others, and once you understand the difference, you'll make far better decisions in allocating resources to carry out the high-priority ones. Requirements gathering is never finished until after the system is deployed. The very presence of an executable system changes the way stakeholders view the problem.
One very important implication of these observations -- as Don Ferguson notes -- is that mature organizations carry out iterative and incremental processes whose primary artifacts are executables. This forces a regular rhythm upon the development team whereby new requirements can be discovered over time, old ones reprioritized and sometimes discarded, and above all, every requirement is measured against reality, not documents.
Understand the real needs
 One observation I have is that businesses are not very good at understanding their own needs, and IT usually makes a big mistake if they assume that they do. Like a patient that goes to the doctor demanding a specific treatment, the business often expresses its needs in terms of the needed solution rather than the business outcome they want to achieve. In the context of a client I recently met with, the business team will say "we need a new insurance claims system." What they really need, though, is to improve their performance in processing claims by X%
or to reduce cost by Y%, or the like. A new claims system may or may not deliver this improvement, but it almost certainly cannot deliver it if the real needs are unknown.
|
Like a patient that goes to the doctor demanding a specific treatment, the business often expresses its needs in terms of the needed solution rather than the business outcome they want to achieve.
-- Kurt Bittner
|
|
Because of lack of clarity about real needs, more focus is needed on helping extended teams of both business people and IT people to understand the real needs. The help of an expert facilitator is often needed to help to guide and depoliticize the discussion. I agree wholeheartedly with Kerrie that some of the greatest challenges are "people problems" caused by misaligned values and objectives between the business and IT, different cultures, and reward structures that reinforce different objectives between the organizations. The best tooling in the world cannot overcome this, and, in fact, may make things worse. Power tools in the hands of an inept craftsman merely create scrap faster.
Sometimes it's easier to sidestep the human issues and try to solve the problem with technology. People and organizations don't like to change, but most improvements require change, and failing to address this often leads organizations not to tackle the cultural/values gap problem head on.
Empowering business analysts with well-expressed requirements
 Business needs can be captured, interpreted, and transformed into functional and nonfunctional IT requirements that will support the business.
Business needs are captured through an analysis of business processes, business goals, business entity types, and business models of decision making. They should be measured or measurable through a set of key performance indicators in order to provide feedback about the degree of success of implementing the requirement and satisfying the business need.
They are interpreted through a process of partitioning, decomposition, refinement, mapping, and analysis of variations (variation-oriented analysis and design). Partitioning is the decomposition of the business domain into its constituent types of domains or functional areas. This represents the structural partitioning. The decomposition of the business is an interpretation of how processes are broken down into subprocesses and use cases. The process of decomposition creates a hierarchy while refinement elaborates that hierarchy into a set of actionable, goal-oriented interaction sequences.
|
(Business) process modeling is essential to the understanding of how a business functions. Some prefer use-case modeling or business use-cases. Ultimately, it is about documenting the dynamic ,or flow,aspect of goal-oriented business activities.
-- Ali Arsanjani |
|
The mapping of business needs to IT requirements requires showing how a given business requirement is traceable and is supported by a set of mutually complementary IT functions, supported by nonfunctional aspects. This mapping is often done through goal-service modeling. We go over the variations and identify commonality between processes, domains/functional areas, and rules.
The process of transformation of needs into IT services can be done through a combination of the following complementary techniques:
- Domain decomposition (includes process decomposition, functional area analysis, and variation-oriented analysis)
- Goal-service modeling
- Analysis of existing assets (includes existing systems, packaged applications, and any assets we can leverage, such as standards, frameworks, domain languages, etc.)
Key to this process is to identify pain points and business drivers relevant within a given time frame beyond which we will have change, and thus, need to apply variation-oriented analysis. Then, we work from these important starting points to refine our understanding into actionable IT requirements that can be satisfied through a combination of functional and nonfunctional requirements.
Requirements engineering for a simple project is different in scope and depth from that of a line of business or an enterprise and the value chain. Recall that business needs are often a snapshot of a point in time and can change drastically. The differentiating business capabilities do not tend to drastically change with time, but are refined. The base capabilities eventually become part of the "woodwork," but should in any case be supported by the IT system.
Every domain will also have a language embedded in it that can be used to describe the problems of that domain. Tapping into this underlying semantics is key to the understating of the intention behind the needs and thus provide requirements that fulfill those intentions.
For SOA or component-based approaches, I recommend using the service-oriented modeling approach, which I describe in my developerWorks article,"Service-oriented modeling and architecture."
(Business) process modeling is essential to the understanding of how a business functions. Some prefer use-case modeling or business use-cases. Ultimately, it is about documenting the dynamic ,or flow,aspect of goal-oriented business activities.
The fulfillment of a business need is enabled through the implementation of a set of underlying IT functional and nonfunctional requirements. Being able to express these requirements declaratively -- within the syntax and semantics of the services provided by the business domain -- is very important. This ability can empower business analysts to engage in the software development life cycle.
Few short cuts, pay now instead of later
 One of the primary roles of an IT architect during the initial stage of a project's life cycle is to capture information about the needs of the stakeholders. IT architects must listen to clients and stakeholders, understand their business requirements, and systematically form incrementally more detailed definitions of the structure of IT solutions. The process is often more of an art that is honed with experience, but it must be a disciplined approach.
Two of life's truths that are applicable to the development of IT solutions:
There are few real short cuts.
It's better to pay now instead of later.
More times than not, when I work with customers, the level of requirements documented for software development projects in building IT solutions is sparse, in my opinion. The reason for this lack of definition is that refining business needs to actionable IT requirements is painful work that requires a skilled practitioner (one reason why IT architects are a valued resource). Refining business requirements to IT requirements is hard work, requires attention to detail, and is an iterative process.
The point to be made is that you MUST spend quality time detailing the requirements of your solutions. Statistics show the more time you spend up front, the less time you'll spend in the latter stages of your development process, resulting in a shorter development life cycle. If you're not able to articulate your stakeholders' needs in writing to a level of detail that can be addressed with technology, then you're not finished capturing the requirements for your project.
There are many approaches to refining business needs to high-level requirements and then to technical IT requirements. Modeling is one primary means of capturing an initial set of functional requirements from stakeholders. By creating use cases, modeling process flows, and evolving Unified Modeling Language (UML) interaction diagrams, you can start to refine business requirements into more detailed definitions of what a solution must support or enable. More formal approaches that are used in complex environments include the following:
These methodologies ensure that IT aligns with business goals and positions a company to truly take advantage of the value proposition of SOA.
|
If you're not able to articulate your stakeholders' needs in writing to a level of detail that can be addressed with technology, then you're not finished capturing the requirements for your project.
-- Holt Adams |
|
Making the magical transition from requirements to choosing technologies or products to use in constructing a solution can be a challenge. An architect's own experience from past projects will influence these decisions, but an architect must also honestly evaluate for each requirement, the IT capabilities that are essential to address the needs. After IT capabilities are identified, an architect can map these capabilities to architectural components and thus, to technology and products, to incrementally add more detailed definitions to the structure of their solutions. In developing an architecture for a solution, an architect should leverage the capabilities of tools to capture and manage requirements, model business organizations, needs and processes, refine and map requirements to IT capabilities, and identify architectural components and technology/products.
About the experts
Bobby Woolf
Bobby Woolf is a member of IBM Software Services for WebSphere, consultants who help customers achieve success with WebSphere products. He is a coauthor of Enterprise Integration Patterns and The Design Patterns Smalltalk Companion. Read more at Bobby's blog on developerWorks.
Andras Robert Szakal
Andras Robert Szakal is chief architect for the IBM Federal Software Group and is a distinguished engineer and Senior Certified IT Architect. He is also serves on The Open Group Board of Directors.
Mark Linehan
Mark Linehan is a senior technical staff member in the IBM Software Group Emerging Technologies department. During the past few years, he’s worked on business rules technology. Previously, Mark developed cryptography-based communication protocols, and designed and developed various communications software.
Calvin Lawrence
Calvin Lawrence is an executive architect on the IBM Software Group Emerging Technology team. His responsibilities include advancing strategic IBM architectures, technologies and products in support of key strategic initiatives and ensuring the success of customer implementations using IBM technologies. He is former Chair of IBM Software Group Worldwide Technical Leadership Council.
Christina Lau
Christina Lau is an architect on the On Demand Development team. Her current projects include creating Pattern Solutions using Rational Software Architect and piloting business innovation and optimization functions. Christina is a Senior Technical Staff Member and a member of the IBM Academy of Technology. She is also a coauthor of a new book, Introduction to IBM Rational Application Developer.
Simon Johnston
Simon Johnston is a senior technical staff member in IBM Rational Software. He has undertaken a number of standards-related activities for Rational Software and, now, IBM in the area of XML, Web services, and Modeling. Visit Simon's blog on developerWorks.
Kerrie Holley
Kerrie Holley is Chief Technology Officer for IBM’s Services Oriented Architecture and Web Services Center of Excellence. His expertise includes software engineering, architecture, and translating business requirements into designs for network-centric distributed solutions.
Donald F. Ferguson
Donald Ferguson is one of 53 IBM Fellows (IBM's highest technical position) in IBM's 200,000-employee technical team. Don is also the Chief Architect for IBM Software Group. Don chairs the SWG Architecture Board, which oversees the architecture and integration of WebSphere, DB2® Information Management, Lotus®, Tivoli®, and Rational® products. Don was the original Chief Architect for the WebSphere family of products. He joined IBM Research in 1985. His interests include raising and playing with his children, distributed systems, simplifying application development, systems management, Web services, transaction processing, performance, and karate. Read his blog, Middleware and tools.
Sanjay Bose
Sanjay Bose works for the IBM Software Strategy division and leads the Enterprise Integration Design Center to identify IBM Software portfolio requirements, and develops solution components and assets by engaging enterprise clients and IBM Software product development laboratories. He has more than 12 years of IT industry experience, primarily focused on creating product architecture and design, articulating technical strategy, and designing enterprise application systems using distributed technologies. His areas of expertise include SOA, Enterprise Service Bus (ESB), Web services, Java™ 2 Platform, Enterprise Edition (J2EE), and e-business technologies. He has coauthored the book, SOA Compass, and has published articles on IBM developerWorks and Systems Journal. He lives and works in Pittsburgh, Pennsylvania, and his spare time is spent with philosophical ramblings, books, movies and his Sony PlayStation. Read his blog, SOA, ESB, and beyond.
Grady Booch
Grady is an IBM Fellow who has served as architect and architectural mentor for numerous complex software-intensive systems around the world in just about every domain imaginable. Grady is the author of six best-selling books and has published several hundred articles on software engineering, including papers published in the early '80s that originated the term and practice of object-oriented design. Read his blog, Software architecture, software engineering, and Renaissance Jazz.
Kurt Bittner
Kurt Bittner works on product strategy for IBM Rational software. He has been trying to figure out better ways to help teams develop software for more than twenty-three years. He was a member of the original RUP® development team and has led development teams in a variety of industries. When not focusing on software development, he likes to relax by climbing frozen waterfalls. With Ian Spence, Kurt coauthored Use Case Modeling(Addison-Wesley, 2003) and Managing Iterative Software Development(Addison-Wesley, forthcoming 2006).
Ali Arsanjani
Ali Arsanjani, Ph.D, is Chief Architect for the SOA and Web Services Center of Excellence within IBM Global Services, specializing in harvesting and developing best practices for the modeling, analysis, design, and implementation of SOA and Web services. He leads the internal IBM worldwide SOA and Web Services Community of Practice (4000 members) and is the principal author of the (Service-Oriented Modeling and Architecture) SOMA method for SOA. He is currently focusing on SOA Tooling with support for Modeling (SOMA), Assessments, Strategy and Planning, Governance, Architecture, and Realization, and their practical application to engagements inside and outside of IBM. Read his blog, Best Practices in Service-Oriented Architecture.
Holt Adams
Holt Adams is an Executive IT Architect on the IBM Software Group Emerging Technology team where he's currently supporting IBM's jStart Program and Customer Innovation Team. As a Solution Consultant IT Architect, responsibilities include combining customers' business requirements with emerging technologies yet to be incorporated or newly incorporated into IBM products. During his tenure in the jStart Program and other services-related jobs, his technology portfolio has included wireless/pervasive computing, Internet infrastructure, Java/J2EE, XML, Web services/SOA, rich Internet applications, and LAMP (Linux, Apache, MySQL, PHP, Perl, and Python) technologies. He is also Contributing Editor to this month's Insight and outlook column.
Resources
About the author
Rate this page
| 
