Strategic e-Business Patterns and Best Practice. Steven J. ... Since the mid-1990's in the field of object-oriented software design, it has become practice to take ...
Linking Requirements Goal Modeling Techniques to Strategic e-Business Patterns and Best Practice Steven J. Bleistein1 , Aybüke Aurum1 , Karl Cox2 , and Pradeep K. Ray1 1
School of Information Systems, Technology and Management, 2 School of Computer Science and Engineering 2National ICT Australia University of New South Wales, 2052 Sydney, Australia s.bleistein@, aybuke@, karlc@cse., p.ray@{unsw.edu.au}
Abstract. We propose that requirements for strategic-level IT systems for e-business can be linked to business strategy via techniques in goal modeling. We further propose that there exist repeating patterns of best practice in business strategy, which are based on recurring business models. These patterns have both direct and indirect implications for systems requirements, and thus identification of these patterns facilitates the requirements discovery process for strategic-level information systems initiatives i n business. These patterns moreover help ensure alignment of systems requirements with business strategy.
1 Motivation In recent years, e-business has changed the role of information technology inside a business. Rather than being an inward-facing, internal support function, e-business has turned information technology into an outward-facing means of interacting with external suppliers, customers, and business partners [19]. This is to say that IT has evolved beyond the role of supplying supporting services to business, to being part of the core of the business. In e-business, IT strategy and objectives have in effect become inextricably intertwined with business strategy and objectives [4].
Fig. 1. IT Shift in Strategic Hierarchy
We argue that inside businesses that undertake e-business initiatives, the function of information technology has therefore shifted upward, from the operational and tactical to the strategic, which we illustrate in Fig. 1. The success of information systems projects inside a business has always required a high degree of alignment with business objectives in order to be successful [18]; however, this shift brought about by ebusiness technology, from the inward-facing, tactical-level information systems projects to outward-facing, strategic-level e-business initiatives, makes alignment of systems requirements with strategic business objectives only more critical. For the requirements engineer, this means that the tools and techniques must integrate means of capturing systems requirements such that they are in alignment with the highest-level of business objectives in order to ensure success. Moreover, as in all areas of IT, requirements engineers find themselves under increasing pressure to deliver solutions with a high degree of quality in a timely manner, and with confidence in their work. The primary aim of this paper is to propose a position on an approach to requirements engineering for strategic-level e-business systems. We propose that goaloriented modeling techniques from the field of requirements engineering can be used as a means of modeling and representing business strategy while simultaneously providing a traceable and explicit link to systems requirements at lower levels. This paper further proposes that strategic-level business models tend to recur, and thus best practices and business strategy to address the challenges posed by these models tend to recur. These recurring strategies and practices can be linked into recurring patterns of requirements. Finally, this paper illustrates how modular patterns for systems requirements using goal-oriented modeling can be derived from business research in management science literature, and how leveraging these patterns facilitate and enhance the work of the requirements engineer. This paper is organized in the following way: section 2 discusses current use of patterns for e-business. Section 3 discusses the meaning of business strategy and business model. Section 4 discusses linking systems requirements with business strategy. Section 5 discusses deriving patterns of requirements based on research appearing in management science and business literature. Section 6 spells out the significance of strategy-oriented patterns to the requirements engineer.
2 Patterns for e-Business Originally proposed in the field of architecture and urban planning [1], the concept of design patterns has been adapted for application in the field of software development and systems design. Design patterns are a means of providing reusable solutions to repeating problems. They enable systems designers to leverage the cumulative wisdom of designers who have addressed the same problems with good solutions before them. Since the mid-1990’s in the field of object-oriented software design, it has become practice to take advantage of design patterns as introduced by the now famous “Gang of Four” [7]. Certain problems in software design and development recur over and
over again. It is not necessary to reinvent a solution for each instance of the same kind of problem. Design patterns in software engineering enable software designers to build on the collective skill and experience of highly capable software engineers. The concept of design patterns in software engineering has been expanded and applied to the development of e-business systems in both industry and government [11] [5]. Researchers at IBM have developed design patterns for e-business architectures [11]. The IBM e-business pattern methodology identifies business patterns based on patterns of interaction between user group roles via tasks. Business patterns highlight the most commonly observed interactions between participants in an e-business system: users, businesses, and data. The United States Federal Government, based on the “E-Government Strategy” recommendations of the Executive Branch, initiated the Federal Enterprise Architecture Program Management Office (FEAPMO) [3]. The mission of FEAPMO is to facilitate efforts in e-government transformation via a business-based architectural framework. For this purpose, FEAPMO has developed the Federal Enterprise Architecture (FEA) [4] described in Fig. 2. The FEA’s “business-driven approach” identifies repeating patterns of business services across the myriad of agencies that make up the Federal Government of the United States [4].
Fig. 2. Federal Enterprise Architecture (FEA) Framework [5]. The FEA is in fact a multilayered architectural pattern, starting top-down with non-functional requirements at the Performance Reference Model layer (PRM), business processes at the Business Reference Model layer (BRM), and logical components at the Service Reference Model layer (SRM), on downward.
These “high-level” frameworks for business patterns in use in industry and government are primarily based upon recurring patterns in processes and tasks, represented in what IBM describes as “business models” [11] and what the FEA describes as “business services” [5] present in its Business Reference Model (BRM) layer (shown in Fig. 2). Patterns are determined via component-level interactions between users, the business, and data in the system. In both these models, however, there is no linkage
between the requirements of the service-level components and the strategic objectives of the business. Other works also propose high-level IT modeling methods and requirements analysis for business [15] [11]. Kilov in his work on business models for IT [15] claims to offer a means of “codifying corporate strategy” in terms of business modeling; however, Kilov’s view of business strategy is one based on classical economics, rather than modern business literature on competitive strategy. Kilov moreover fails to show the linkages between his lower-level business modeling to higher levels of strategy. Hay proposes requirements analysis from different business perspectives in the context of the Zachman framework for architecture [11]. The Zachman framework provides multiple perspectives on business strategy based on business motivation; however, the Zachman framework does little to enable linkages between strategy and lower-level rules, processes, and requirements. Moreover, Hay does not mention the concept of recurring patterns of strategy. Gordijn and Akkermans propose the e3-value approach, a value-based requirements engineering methodology, involving multiple business stakeholder perspectives, to trace requirements to business value across a value model [9]. This model is meant for use in IT-intensive e-commerce businesses in order to align IT with business strategy. It is further intended to provide greater assurance that the e-commerce proposition will generate value for the business. The proposed approach, however, lacks some fundamental analysis that normally appears in any business proposition for the purpose of valuation, such as market readiness, market potential, competitor analysis, strategic positioning, and overhead required to support the IT infrastructure and operations.
3 Business Model and Business Strategy We base our concept of strategy primarily on the work of Michael Porter on competitive strategy [20]. Strategy is broken into two components: unique strategy and operational effectiveness. Both components are essential to a successful business strategy. Unique strategy concerns what a company does differently from its rivals, in processes, use of resources, use of technology, etc. in order to provide competitive advantage for itself. Operational effectiveness, however, is about performing activities and using technology according to known best practices. In essence, unique strategy is about how a company does things differently from rivals, and operational effectiveness is about how companies do, or should do, things in the same best way. We define business model as a macro-level model of interaction of participants in a business system. The e-business models described in the subsequent section are based on the patterns of interactions between the company, customers, and suppliers, and the flows of money and information described by Weill and Vitale [23]. The business models used here define a “big picture” of the business as a whole, rather than smaller processes, services, and components as appear in Kilov’s concept of business models [15].
Thus, business strategy concerns what the company does specifically in order to generate value in the context of the business model. Therefore, based on the above definitions, we propose that business strategy is in fact constructed in the context of the business model.
4 Linking Requirements to Strategy The framework we propose links business goals to higher-level business strategy and business models as a means of enforcing strategic alignment of systems requirements as we describe in Fig. 3.
Fig. 3. Proposed Framework for Strategy-Oriented Requirements. Business strategy i s derived from the business model. A goal model is derived from business strategy. Business processes support goals, and business processes determine the requirements of the system.
Porter represents business strategy with “activity-system mappings” modeling notation. This notation identifies higher-level strategic themes implemented through clusters of “activities” [20]. Porter’s “activities” are essentially equivalent to abstract objectives in a goal model. Therefore, we propose that business strategy can be represented in terms of a collection of high-level abstract business objectives. Thus goaloriented modeling tools provide a means of representation of systems requirements down through the layers of the strategic framework proposed in Fig. 3. Goal-oriented modeling notation has been proposed before as a means linking highlevel business goals to systems requirements in the context of recurring patterns. Gross and Yu proposed using NFR Framework to model patterns of non-functional requirements linked to organizational and systems objectives and business goals [9]. While a number of goal-oriented modeling notations exist, we propose using goaloriented requirements language (GRL) notation [8] [16] as a standard base notation for modeling patterns of business strategy. The decision to adopt GRL for this purpose is based on the following reasons: - GRL is an emerging standard, and is under consideration for adoption as a standard by the ITU-T [13]. - GRL is flexible enough to model abstract strategic objectives and supports decomposition modeling down to implementation.
- GRL is a goal-oriented modeling notation in the field of requirements engineering, and is appropriate for use by requirements engineers. - GRL encompasses modeling of both functional and non-functional requirements enabling systems modeling that integrates both strategic objectives, functional, and non-functional requirements.
5 Patterns of Requirements Derived from Business Models A number of problem domain modeling approaches for requirements engineering have been suggested. For example, Rubenstein and Waters [21] introduced what they called clichés for seven distinct problem domains. At a different level of abstraction, Sutcliffe and Maiden [22] present over 200 object system models from the NATURE project. Maiden and Hare [17] show ways to determine which problem category one requires for the NATURE patterns [22] by using a card slot approach. Coad et al. [2] presented a number of object patterns and strategies for analysis modeling; these though appear more at home in early design. Fowler [6] presents a large number of analysis patterns, described in a hybrid object-oriented modeling notation specifically for the financial domain again closer to design than business. Jackson's Problem Frames [14] describes five different problem domain patterns suggesting that each needs a different development approach. None of these address business needs in terms of strategy but are more tactical and/or operational and closely tied to software solutions. While fields such as computer science, information systems research, and software requirements engineering may not have much research to offer on repeating, high-level patterns in business strategy based on business models, management science and business literature are replete with this kind of research. This section examines the possibility of using research in management science as a basis for discovering strategy patterns that can be applied to requirements engineering in the context of the framework proposed in the previous section (Fig. 3). In particular, in this section we examine atomic e-business models in research presented by Peter Weil and Michael Vitale [23] [24]. Weill and Vitale examined e-business initiatives across Australia and around the world. They were able to identify eight atomic business models across the companies they surveyed (see Fig. 4). Each atomic model, is characterized by (1) flows of money and information; (2) the participants in the model, the business, suppliers, and customers; and (3) the relationships between the participants. From each atomic model, Weill and Vitale were able to identify critical success factors, core competencies, and IT infrastructure requirements representing best practices for each type of model. Each of these areas has both direct and indirect implications for requirements for the e-business system, which can be represented in terms of a goal model (an example model for Value Net Integrator appears in Fig. 5). We propose that a collection of these types of goal models based on composite business models can serve as a means of guiding the requirements elicitation and discovery process for
e-business initiatives. These goal models further help ensure strategic alignment of the resulting requirements with best-known practices for the business model identified.
Fig. 4. Atomic Business Models [24]. This chart lists the eight models identified b y Weill and Vitale and provides a brief description of the business associated with the model. The original research also describes patterns of interaction of the participants as well as flows of money and information [23].
Atomic models for e-business can serve as a basis for patterns of requirements. The goal-models attached to the business model represent best practices as a component of strategy. The concept of best practices for operational effectiveness is equivalent to the concept of design patterns in that the premise of both concepts is the same: leveraging cumulative wisdom on order to provide generalized solutions to recurring problems. Moreover, atomic e-business models are modular. Atomic models can be combined in order to form more complex composite models of e-business initiatives. In this way, the atomic e-business models are similar to design patterns in general, such as design patterns for object-oriented software [7], and urban planning and architectural patterns for towns, buildings, and construction [1], which are also modular. Thus, the atomic models for e-business are quite appropriate and useful as a basis for patterns of requirements according to strategy.
Fig. 5. This figure represents a collection of goal models for the Value Net Integrator atomic business model using GRL notation [8]. The soft-rounded rectangles represent “softgoals,” or goals whose achievement is abstract and difficult to measure. Elongated hexagons represent implementations or operationalizations. Rectangles represent contributing resources. The large softgoals at the top of the model are meant to describe the strategic themes of the business model in similar fashion to Porter’s activity-systems mappings [20]. The other entities in the model represent smaller objectives, resources, and implementations that support the strategic themes. Because of limitations for this paper, we have left this model incomplete. There would exist more goals and further decomposition down to a more granular level in a complete model. Note: This diagram was created using the OME3 modeling tool, which is available for download at the GRL Web site [8].
6 The Significance to the Requirements Engineer Patterns of requirements in terms of operational effectiveness based on business models are important to the requirements engineer for two reasons. First, understanding the business model and a company’s overall strategy makes it possible to identify known best practices that address the challenges posed by the business model. The best practices, representing the operational efficiency component of business strategy, have both direct and indirect implications for systems requirements. In essence, understanding the business model can mean knowing a large number of systems requirements in advance of stakeholder interviews while also having confidence in the quality and appropriateness of those requirements thanks to cumulative industry experience. Second, understanding a large amount about systems requirements that support known best practices allows the requirements engineer to focus more effort on the requirements that support the unique strategy of the business, which can be more
elusive but critical to the success of the business. Particularly when a requirements engineer has difficulty commanding the time and attention of managers in stakeholder interviews, means of expediting the process can be particularly helpful.
7 Conclusion Because the role of information technology in e-business resides at the strategic level of companies, clear alignment between requirements and business strategy can be critical to the success of the company’s core business. We propose that requirements for strategic-level IT systems can be linked to business strategy via techniques in goal modeling, and proposes a framework in which to do so. It further proposes that as part of business strategy there are repeating patterns of best practice based on recurring business models. These patterns have both direct and indirect implications for systems requirements. Thus understanding the business model enables identification of patterns of best practice as part of strategy, and therefore recurring patterns of requirements. These patterns support the requirements engineer in two primary ways: first they facilitate and expedite the requirements discovery process for strategic-level information systems initiatives in business while allowing the requirements engineer to have confidence in the quality and appropriateness of those requirements. Second, understanding a large amount about systems requirements that support known best practices allows the requirements engineer to focus more effort on the requirements that support the unique strategy of the business. While this research is still in the preliminary stages of investigation, it serves as a base for further development of the framework and other concepts proposed.
References 1. 2. 3.
4. 5. 6. 7.
Alexander , C., Ishikawa S., Silverstein, M.: A Pattern Language: Towns, Buildings, Construction. Oxford University Press, 1977. Coad, P, North, D., Mayfield, M: Object Models: Strategies, Patterns and Applications, Yourdon Press, 1995. E-Government Strategy: Implementing the President’s Management Agenda for EGovernment, Simplified Delivery of Services to Citizens. Office of Management and Budget, Office of the President of the United States, February 27, 2002. Earl, M., Khan B.: E-Commerce is Changing the Face of IT. MIT Sloan Management Review, Fall, 2001. Federal Enterprise Architecture Program Management Office, Federal Enterprise Architecture (FEA), http://www.feapmo.gov, May, 2003. Fowler, M.: Analysis Patterns, Addison-Wesley, 1996. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Publishing Company, 1st edition, 1995.
8.
Goal-Oriented Requirements Language: URL: http://www.cs.toronto.edu/km/GRL, May 2003. 9. Gordijn, J., Akkermans, J.: Value-based requirements engineering: exploring innovative ecommerce ideas. Requirements Engineering Journal, 8:114-135, 2003. 10. Gross, D., Yu, E.: From Non-Functional Requirements to Design Through Patterns. Requirements Engineering, 6:18-36, Springer-Verlag Lodon, 2001. 11. Hay, D.: Requirements Analysis: From Business Views to Architecture. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2003. 1 2 . IBM corporation: IBM Patterns for E-Business. URL: http://www106.ibm.com/developerworks/patterns/, May, 2003. 1 3 .International Telecommunications Union Study Group 17, URL: http://www.itu.int/ITU-T/studygroups/com17/index.asp, May 2003. 14. Jackson, M.: Problem Frames, Addison-Wesley, 2001. 15. Kilov, H.: Business Models: a Guide for Business and IT, Prentice Hall PTR, Upper Saddle River, NJ, USA, 2002. 16. Liu, L., Yu, E.: From Requirements to Architectural Design - Using Goals and Scenarios. ICSE-2001 Workshop: From Software Requirements to Architectures (STRAW 2001), Toronto, Canada, pp. 22-30, May 2001. 17. Maiden, N., Hare, M.: Problem domain categories in Requirements Engineering, International Journal on Human-Computer Interaction, 49, 281-304, 1998. 18. Nell, C.: Business and Systems Development: Opportunities for an Integrated Wayof-Working. Perspectives on Business Modeling, pp. 197-212, Springer Verlag Berlin, Heidelberg, New York, 1999. 19. Pinker, E., Seidman, A., Foster, R.: Strategies for Transitioning ‘Old Economy’ Firms to e-Business. Communications of the ACM, Volume 45, Issue 5, May, 2002. 20. Porter, M.: What is Strategy? Harvard Business Review, November-December, 1996. 21. Reubenstein, H., Waters, R.: The requirements apprentice: automated assistance for requirements acquisition, IEEE Transactions on Software Engineering, 17, 226-240, 1991. 22. Sutcliffe, A., Maiden, N.: The Domain Theory for Requirements Engineering, IEEE Transactions on Software Engineering, 24, 174-196, 1998. 23. Weill, P., Vitale, M.: Place to Space: Moving to eBusiness Models. Harvard Business School Publishing Corporation, Boston, 2001. 24. Weill, P., Vitale, M.: What IT Infrastructure Capabilities are needed to Implement EBusiness Models, MIS Quarterly Executive, Vol. 1, No. 1, March 2002.
