Towards Improving Enterprise Architecture Decision-Making through Service-Dominant Logic

Transcription

1 Association for Information Systems AIS Electronic Library (AISeL) PACIS 2010 Proceedings Pacific Asia Conference on Information Systems (PACIS) 2010 Towards Improving Enterprise Architecture Decision-Making through Service-Dominant Logic Cheng-Hui Chuang University of Pretoria Johan van Loggerenberg University of Pretoria Hugo Lotriet University of Pretoria Follow this and additional works at: Recommended Citation Chuang, Cheng-Hui; Loggerenberg, Johan van; and Lotriet, Hugo, "Towards Improving Enterprise Architecture Decision-Making through Service-Dominant Logic" (2010). PACIS 2010 Proceedings This material is brought to you by the Pacific Asia Conference on Information Systems (PACIS) at AIS Electronic Library (AISeL). It has been accepted for inclusion in PACIS 2010 Proceedings by an authorized administrator of AIS Electronic Library (AISeL). For more information, please contact

2 TOWARDS IMPROVING ENTERPRISE ARCHITECTURE DECISION-MAKING THROUGH SERVICE-DOMINANT LOGIC Cheng-Hui Chuang, Department of Informatics, University of Pretoria, Pretoria, South Africa, Johan van Loggerenberg, Department of Informatics, University of Pretoria, Pretoria, South Africa, Hugo Lotriet, Department of Informatics, University of Pretoria, Pretoria, South Africa, Abstract Enterprise architecting is a complex process that includes incorporating knowledge, processes, systems, technologies, and people. In order to ensure the appropriate value integration in this complex process, key fundamentals for value integration need to be explored and studied in this context. Previous research has shown that architecture management and business strategy are still largely disintegrated and misaligned on many levels. Hence, this paper aims to describe the role of service science, specifically the service-dominant (S-D) logic, within the overall enterprise architecture (EA) environment as a potential perspective that will allow alignment and integration. The paper uses the architectural decision-making scenario to illustrate the gaps for contribution, and to argue that service science has the key ingredients that should be used to facilitate value integration in enterprise architecture environment. Architectural decision-makers including enterprise architects and business managers can ultimately benefit from using service science as a strategic logic to better integrate values in their decision-making process. Keywords: Enterprise Architecture, Service-Dominant Logic, Architectural Decision-Making, Value Integration 1263

3 1 INTRODUCTION The services sector has lately become the largest part of most nations economies (Spohrer et al. 2007). Escalating economic and societal demands, together with the emergent service domination, undoubtedly set a growing agenda for architectural institutionalization within the organization. The complexity created by rapid technology advances and changing business needs caused organizations to seek for a blueprint which facilitates a common goal to achieve organizational strategic objectives. Enterprise architecture (EA) essentially aims to provide a blueprint for the effective utilization of organizational resources while pursuing to be more agile, integrated, and aligned (Armour et al. 1999; De Vries & van Rensburg, 2008; Boster et al. 2000; Jonkers et al. 2006). However, managing EA is a complex process and includes the integration of knowledge, processes, systems, technologies, and people. EA initiative is often constrained by the complexity of its integrated nature. Typical challenges are suggested in recent studies, ranging from social issues (Chuang & van Loggerenberg, 2010; van der Raadt et al. 2008) to organizational issues (Espinosa et al. 2010; Chuang & van Loggerenberg, 2010; van der Raadt et al. 2008; Kaisler et al. 2005) to technical issues (Kaisler et al. 2005). Organizations, therefore, are often faced with a mixed set of challenges demanding a multidisciplinary approach to address the challenges before one can materialize the business values of EA. In order to ensure the appropriate value integration in EA, key fundamentals for value integration need to be explored and studied in this context. This paper aims to describe the role of service science, specifically the service-dominant (S-D) logic, within the overall EA environment. This research makes use of architectural decision-making to illustrate and to argue that service science has the key ingredients that can be used to facilitate value integration in the EA environment. Taking into consideration that the current business challenges are largely intertwined in nature, service science provides the required multi-disciplinary approach as the foundation for value integration. 2 MOTIVATION There is increasing attention on using EA to assist organizations to manage change and complexity. One therefore needs to explore and identify the key fundamentals that can be used to facilitate value integration in the overall architecting process. Currently challenges facing the organization and enterprise architects are largely a mix of technical, organizational, social, and economical aspects. A typical example of such challenge is found in architectural decision-making. In this scenario architectural decision-makers often lack the understanding and the support for managing and assessing decisions in the larger business strategic context. Moreover, the relationships and the linkages between EA and the business strategy are still not clearly defined and understood by all stakeholders. Inconsistencies and non-alignment were found between the stakeholders, including between members of the architecture teams. This paper proposes that service science, specifically S-D logic, is essential for integrating value in the EA environment. Service science is multi-disciplinary in nature, thereby combining the ingredients of various disciplines. It seeks to tackle the core problems of innovation, including how to restructure organizations, how to manage technological innovation, and how to simulate systems with complex behaviours (Abe, 2005). Service science, as proposed in this paper, has the key ingredients that can be used to address the challenges in the overall EA environment. This paper, based on the findings of the architectural decision-making scenario, presents a conceptual viewpoint on how service science, through application of S-D logic, can play a key role in understanding and analyzing value integration in the EA environment. 3 CONTEXT OF RESEARCH EA is a popular tool which is used to help organizations to be more agile, integrated, and aligned. However, the resources available to build any architecture are limited. Investing in an organization s EA thus requires careful resource considerations at managerial level. Business and architectural 1264

4 decision-makers must consider the implications of architectural decisions, and how they potentially support the organizational strategy so that the limited resources can be effectively applied. This, however, can only be achieved based on a clearly defined relationship between business strategy and EA on various decisional levels. The evidence found in this research contributes to the overarching context by showing that currently values are manufactured and delivered in silos, and because of its disintegrated nature, it consequently causes architectural decision to be sub-optimal. Such evidence is crucial to substantiate the inappropriate investment of organizational resources on EA. The role of service science is argued to be essential for the establishment of the strategy-ea relationship. Hence, this research ultimately forms part of the bigger argument on the need for effective application of organizational resources on EA. 4 LITERATURE REVIEW 4.1 EA and architectural decision-making Zachman (1997) defined EA as descriptive representations that are relevant for describing an enterprise such that it can be produced to business requirements and maintained over the period of its useful life. The primary objective of EA, as described by Zachman, is to assist organizations to manage change and complexity. Chuang and van Loggerenberg (2010) consolidated the definitions of various researchers (De Vries & van Rensburg, 2008; Jonkers et al. 2006) and described EA as a management practice that consists of principles, means, and representations that provides present and future organisational configurations in terms of structure, processes, systems and infrastructure. Others (Ross et al. 2006) contextualised the strategic nature of EA in their definition by suggesting a long-term view of organizational configuration of processes, systems, and technologies, thereby creating an agile capability to link an organization s operating model and IT engagement model. It is argued that EA is about building capabilities rather than building a system of systems. EA is strategydriven in nature; a business tool that builds a foundation for strategy execution through assisting the business decisions-makers in engineering the enterprise in line with the business strategies and objectives. Architectural decisions are decisions that concern the architecture as a whole, or one or more of its core components, and their relationships (Zimmermann et al. 2006; Tyree & Akerman, 2005). In EA, architectural decision-making is characterised by its enterprise-wide scope. The decisions in architecture planning and design often have an influence on the overall organization, and it typically involves multiple stakeholders, perspectives and requirements, and technical decisions (Kazman et al. 2002). Key stakeholders usually join together to make certain decisions concerning the architectural plans, design frameworks, defining and establishing of architectural goals and objectives. These decisions are then further translated into a set of business and architecture requirements that will be used to guide the architecture planning and design in different architectural domains, such as the as-is analysis and architectural processes for planning for the to-be architecture. With more organizations realizing the disadvantage of having business silos (van der Raadt et al. 2008; Zachman, 1997), EA has created increasing expectations to achieve certain benefits and values. The drivers for the expectations of benefits and values can vary from one organization to the next. Organizations often expect both business- and IT- related benefits of EA. For example, the research conducted by Shar and Kourdi (2007) lists a number of benefits that a typical organization would expect from EA. Business benefits such as governance management, enterprise integration, business decision support, faster adaptability, and process improvements are typically expected. IT benefits typically include complexity management, standardization, IT resource oversight, knowledge management, and IT visibility. The representative enterprise layers and modular components allow the organization to be more agile, and be able to conduct business decisions in the context of the whole. Hence, EA provides a holistic, integrated approach for organizations to manage change and complexity in achieving the strategic goals and objectives of the business. 1265

5 4.2 Service science: S-D logic vs. G-D logic The concept of service has been widely used across diverse contexts and disciplines. However, while the majority of computer scientists associate the term service to web services and service-oriented architecture (SOA), there is a broader story to be told of the remarkable growth in the transitioning into service economy (Spohrer & Riecken, 2006). Service science is a new discipline that encompasses the inter-disciplinary studies of computer science, operations research, mathematics, decision-making theory, social and cognitive sciences, and other fields. According to Spohrer et al. (2007), service science entails the value co-production configuration of people, technology, other internal and external service systems, and shared information such as language, processes, policies and laws. It ultimately encompasses people and technology which adaptively adjusts to a system s changing value of knowledge (Spohrer et al. 2007). Service system is represented by different entities such as the organization, business unit, household, individuals and systems with knowledge works (Maglio et al. 2007). Service systems can be connected to each other internally or externally and thereby form a value co-production network consisting of various service systems. Service-dominant (S-D) logic emphasizes the role of customer s involvement within service science. S-D logic suggests that what service providers provide should not be understood in terms of outputs with value, but rather as resource inputs for a continuing value-producing progression. The focus is placed on resourcing rather than producing, and the benefits are always manifested in the context of the customer (Lusch et al. 2008). In essence, the underlying philosophy states that the value is not created by the service provider and then delivered to the customers, but rather that the customer is an integrator of inputs provided by the service provider with its other resources to produce value. Thus, an organization provides only value propositions; it does not produce value. The value can only be coproduced if the customer accepts the value proposition and co-produces the value as a collaborator or integrator (Lusch et al. 2008). In comparison to goods-dominant (G-D) logic, S-D logic focuses on services and how to utilise operant resources. As shown in table 1, operant resources have a more implicit interpretation because of their intangible nature and they are often understood to be capable of acting on operand resources and other operant resources to produce value (Lusch et al. 2008). S-D logic therefore specifies that a service provider make use of both operand and operant resources to provide a service. G-D logic, on the other hand, focuses primarily on the utilization of the physical resources to provide the goods. Although the types of resources utilised by G-D logic and S-D logic have been identified, the process of utilising these resources needs to be explored. It is therefore necessary to further investigate the concept of resourcing. Service-Dominant Logic Goods-Dominant Logic Services Goods Intangible Tangible Operant Resources Operand Resources Value Co-creation Value Added Relational Transactional Table 1: S-D Logic vs. G-D Logic (adapted from Lusch et al. 2008; Hsieh & Yuan 2010) In the G-D logic worldview, the production of value is associated with resource acquisition, and it primarily concerns the physical resources (operand resources) (Lusch et al. 2008). The organisation as goods provider specialises in the production of certain outputs, such as tangible goods, and in exchange for the labour provided by the customers, the customers can then seek the goods the organisation produces. The function of specialisation and exchange forms a continuous cycle of resource acquisition in G-D logic. In contrast, under S-D logic, value creation occurs when a resource is turned into an explicit rather than a tacit benefit. The general principle is that resources do not 1266

6 have intrinsic value, but rather are valued when integrated and positioned through resource-based value-producing network, including the network of customer (Lusch et al. 2008). The process of producing value through transforming and/or integrating resources into an explicit benefit is known as resourcing. In S-D logic, the primary focus of servicing and experiencing is on the interaction between the organization (service provider) and the customer. Emphasis is placed on the significance of the interaction: how the customers in the particular context experience the process of organization in servicing their needs and expectations. This means that the general concern is more than just the transfer of ownership, as it is in G-D logic. It implies something more than just a productivity issue; it strongly affects the experiences of the customers and to a large extent their ability to co-produce value together with the service provider. This perspective highlights that organizations should not only be concerned about the productivity dimension of their employees in terms of effectiveness and efficiency. S-D logic differs fundamentally from G-D logic which is essentially the exchange of ownership of goods. S-D logic states that the organization should pay more attention to the other dynamics of service provision, such as the experience and the productivity of the customer. Given the history of G-D logic and its ties to manufacturing, it is natural that the use of the resources necessary for value production was conceptualised in terms of a linear supply chain (Lusch et al. 2008). In contrast, S-D logic aims to address the dynamics of service provision by re-conceptualising the relationship within the value co-production network in such a way that it does not limit itself to linear, vertical arrangements, rather it can be arranged in an infinite number of ways (Lusch et al. 2008). This re-conceptualisation facilitates innovation and competitive advantage. More importantly, such network includes not only an association of available service systems, but also the final customer in the value co-production network. Thus, customers can simultaneously co-produce value within the network of service providers, service systems, and other service receivers. This paper contextualises the definition of service in such a way so that it encapsulates multiple dynamics when the full spectrum of the service value chain is studied. In other words, it perceives enterprise architects as the service providers who supply the architectural service to whom the organization perceives as the customer. 4.3 Related research on EA challenges EA advocates support for business strategy and providing a long-term, unified view of business configuration of structures, processes and systems. However, the effort for achieving such a goal is also replete with challenges and complexities. The work of Kaisler et al. describes a set of challenges that one needs to overcome to materialize the business values of EA (Kaisler, et al. 2005). Kaisler s work corresponds with the work of Chuang and van Loggerenberg that current challenges are largely non-technical in nature (Chuang & van Loggerenberg, 2010). Most challenges fail to adequately address the human side and the service delivery process of EA. Chuang and van Loggerenberg (2010) suggest that architects are too engineering-minded, their background and worldviews tend to lead them to focus too strongly on the technical side of architecture. It is therefore important to make a transition to understand the non-technical perspective and practice their role accordingly in order to facilitate organizational changes. Kaisler et al. research Chuang & van Loggerenberg research - business view representation and Communication: Both internal communication and communication alignment with EA stakeholders are weak, and it consequently becomes a - stakeholders perspectives barrier to institutionalize EA. - business view representation and Obtaining buy-in from the stakeholders: Negative perceptions alignment about EA, conflict-of-interest among the stakeholders, and inability - stakeholders perspectives of enterprise architects to adapt to the community beliefs of different - the system architect s value stakeholders all results in difficulties in obtaining buy-in. proposition - Ownership: Stakeholders tend to resist the EA initiative because it influences their status of ownership. 1267

7 - Perceptions of the enterprise architect: The worldviews of most architects are largely influenced by their technological or engineering background. - Organizational politics: The nature of the EA environment and the associated decision-making seem to be very politically influenced. - limited modeling tools -managing the integrated enterprise life cycle Other challenges: Integration of legacy systems, limited modeling tools, and a single interface that can interact with all data sources are considered as a few of the technical challenges. Table 2: A high-level overview of the challenges found (adapted from Chuang & van Loggerenberg, 2010) Van der Raadt et al. (2008), and Espinosa et al. (2010) confirmed the need for the architects to pay more attention to the human side of EA. EA planning and design requires close coordination and it involves many stakeholders, such as the business management, project/programme managers, system champions, data owners, policy owners, and enterprise architects. Each EA stakeholder focuses on a specific area of the organization, and they are always in pursuit of specific objectives. However, many of these objectives may be conflicting. It, therefore, causes the architectural decision-making process to be complex due to the multiple implications imposed on numerous organizational areas. 5 RESEARCH DESIGN This research primarily follows a qualitative approach because the subject requires an in-depth understanding of the relationships between the various actors and the associated architectural processes and components. The use of architectural decision-making means that an understanding of the decision-makers perceptions is essential. Hence, a strong interpretivistic, qualitative approach is appropriate for this particular research in order to reveal people s behaviour and their perceptions of a particular situation (Walsham, 1995). Our research is an explanatory study that is based on the findings from the semi-structured interviews and informal discussions with enterprise architects. The field studies mainly focused on the architectural decision-making scenario. The research entails 11 semi-structured interviews, complemented by participating in an EA practitioner s forum and EA research forum. 11 interviews were conducted with enterprise architects working in the relevant EA domains, representing companies across various industry sectors, such as telecommunication, financial services, IT service providers, consulting services, and governmentowned enterprises. The background of the interviewees is largely related to IT specialization, such as computer science, information systems, and computer engineering. These are summarized in Table 3. Throughout the interviews and discussions issues were raised, discussed, and observed. Domain - EA consulting - Senior management for EA portfolio - Business architecture - Application architecture - Information architecture - Technology architecture. Background - Computer science - Information systems - Computer engineering Table 3: A general summary of interviewee s background and the domains for which they work in. 1268

8 6 FINDINGS 6.1 Misalignment between business manager s agenda and architect s agenda Enterprise architects often claim that EA supports business strategy execution and delivers strategic benefits to the business. However, they struggle to live up to the claims they make. One of the critical causes for this failure is the invisibility of business strategy. Most interviewees noted that very rarely they would see a proper strategy document of the business divisions. This implies that the requirements used as input into architecture planning and design are still IT-oriented. Moreover, the trigger for an EA initiative is largely driven by change requests, that is, whenever an initiative requires a change in the IT infrastructure, a request would be submitted to the EA teams. This causes the overall EA and architectural decisions to be rather solution-driven and reactive in nature. Consequently, it essentially positions EA to be IT-centric and IT solution-centric. The interviewees also commented that enterprise architects are largely perceived as techies in the eyes of business managers. As a result, they often show reluctance to engage with the enterprise architects. They perceive enterprise architects as only capable in providing technical services with limited business knowledge. It does not come as a surprise that this often leads to inconsistencies and non-alignment between business strategy planning and architecture planning. Some interviewees conceded that a number of architects indeed live up to their name of a techie. Some only focus on delivering technical products and ignore on the service delivery process. Most business managers expect tangible business results and not IT deliverables and have largely been disappointed in the EA efforts. Because of this isolation of enterprise architects from the business, EA initiatives are often owned and driven by the IT division which further deteriorates the relationship and the misalignment As one interviewee commented, business managers are likely to be more product-driven, whilst most architects are driven by ad-hoc change requests and thereby became more solution-driven. This means that what business managers expect from EA and what architects deliver to the business are misaligned and potentially misunderstood by both parties. Architects do not receive meaningful inputs from the business managers and they similarly do not provide meaningful outputs for the business managers a case of garbage-in-garbage-out squared. Business initiatives will always take priority to EA initiatives. Typically, business managers are more concerned with time-to-market than appreciating what benefits the architecture blueprint might bring. The business would often say they want to launch this new product, and they want to do it next month, we can fix the architecture later, commented one interviewee. EA should therefore ideally be owned by the business, as all interviewees agreed. As long as EA is owned and driven by IT, business managers wll find it difficult to relate EA to their business [strategy], said one interviewee. 6.2 Unable to make relevant architectural decisions for the business Enterprise architects often have limited decision-making power other than in their own domain. Moreover, architectural decisions are strongly influenced by company politics and power relationships. The interviewees acknowledged that many architects have little or no insight into business strategies and are not competent to get involved in company politics and power struggles. However, if the architects are not trusted or empowered to make the right architectural decisions, then EA stands little chance to deliver meaningful value to the business. Hence, it was noted that EA essentially needs a very strong (powerful) business leadership that can steer the initiative throughout the entire organization. Architectural decision-making is often fragmented across various domains of the architecture, thereby making the decisions less relevant to the overall organization. We all still work in silos, said the one interviewee, between business managers and architects, and between architects and architects. It was further noted that currently the EA frameworks or the methodologies are still unclear with regards to the various decision points in the overall architecting process. A decision framework is therefore needed in order to facilitate making relevant architectural decisions. 1269

9 In order to make a decision relevant, architectural decision-makers have to be able to illustrate value of EA to business executives in business terms. When EA is presented to business managers, they see meta-models and process diagrams, but what they are looking for, is the investment value of such EA. Hence, business executives are unable to relate EA in the business context. Architectural decisions are therefore made but they are mostly irrelevant to the business managers. 7 DISCUSSION: THE NEED FOR S-D LOGIC IN EA Our findings show a strong disconnection between the business and EA (as shown in figure 1). Although the communication from business and EA is defined as business requirements, we have indicated that this is still littered with challenges. The communications from EA to business is, however, even more problematic as indicated in our findings. Such disconnections prevent the organization from achieving the business values EA can potentially deliver. Both enterprise architects and business managers need to re-visit their approach in terms of how they manage architectural decisions in order to co-produce values. Figure 1: A graphical illustration of the disconnection between business strategy and EA Building on the foundation of previous researches (as discussed in 4.3), the findings support the literature by further illustrating the current status of the relationship between business and EA. It highlights the disconnection, but at the same time also encourages researchers to seek for a solution. Our suggestion in this paper is the potential contribution of service science, more specifically S-D logic. We propose that service science can play an important role for the reason that the strategy-ea disconnection causes value interruption where each party produces values on its own and deliver in silos. Because these are not integrated, they fail to achieve synergistic objectives. S-D logic, on the one hand, urges architects to become more customer-oriented through a better understanding and appreciation of their customers, the business. On the other hand, S-D logic urges business managers to re-think their role in and attitude towards EA. Only when both service provider (EA) and customer (business) get it right, will synergistic value be co-created. S-D logic describes how architects should ultimately facilitate the value integration process in EA. The transition from G-D logic to S-D logic emphasizes the need for a different approach in today s organization where businesses are service-driven. Organizations need to re-consider its past manufacturing mindset and how one can satisfy the needs and the expectations of the customers. Similarly, one of the reasons for the strategy-ea disconnection, is the approach taken by enterprise architects in co-ordinating the architectural decisions and processes. The architecture teams continuously produce IT deliverables without taking cognizance of what business values are important and relevant to the business. This coincides with the G-D logic of manufacturing the goods and delivering it to the customer. However, one should understand that value is seldom created in silos. S-D logic specifies that customers are integrators of value. In other words, the value is not manufactured and then delivered to the customers. The value is created through providing a value proposition to the customers, and if the customers accept the value proposition, it can act as an input 1270

10 for the value creation. Hence, there are a number of lessons that enterprise architects can learn from the S-D logic in order to facilitate the value integration. To be successful, it is important to appreciate the organizational/social network structure of an organization. One cannot engage the customers in the value integration process if there is no appropriate value proposition to start with. Business managers look at the EA and they look for certain value propositions that are in line with their culture, strategy, and objectives. Hence, the value propositions should reflect what they need to accomplish their goals and not what architects decide they need. The value propositions have to be appropriate for the social structure of the managers. In other words, if time-to-market were important for the business manager; an IT deliverable on its own would not be sufficient as a value proposition. It has to be the business benefits that are in line with creating agile capabilities for faster time-to-market. S-D logic also specifies the importance of the customer experience. Emphasis is placed on the significance of the interaction; how the customers experience the servicing process. The interactions can be understood as the relationship between business strategy and EA, and more specifically, how business managers and enterprise architects interact with each other to achieve a common goal. Cognisance must be taken of the different levels of interaction points in order to enhance the experience and to facilitate the value creation process. That is, value integration has to happen on the basis that different interaction points are clearly defined and synthesized. There are various implications for interacting between business strategy and EA. The one typical example would be that of cultural implications: how architects should interact with the business managers based on the culture of a specific business division. Hence, efforts should be made to enhance the customer experience and thereby to integrate the inputs from various stakeholders to satisfy the values of EA. Figure 2: A conceptual view on how S-D logic assists with value integration on different levels of architectural decision-making As shown in figure 2, the role of S-D logic in EA is to specify the importance of the various interactions with the emphasis placed on the people (customer) and collaboration. The perspective of co-producing values with key business managers is hereby highlighted by the S-D logic. Architects must appreciate that the current disconnection is caused by inappropriate value propositions, poor customer experience, and misalignment of expectations. Hence, S-D logic greatly contributes to the EA architectural decision-making by offering a transitional approach away from the G-D logic. Architects, as service providers, must practise their role as an agent to facilitate value integration and not an enforcer who manufactures and imposes the value onto others. At the same time, for enterprise architects to be successful in their efforts to implement the S-D logic, business must also buy into and 1271

11 adopt S-D logic, understand their role as a customer who provides inputs for the continuing value integration. 8 WAY FORWARD This is a work-in-progress paper which requires further research to enrich and to validate the proposal for its solutions. Research will therefore be carried out to acquire more field data from a wider range of companies. Future research may also include interviewing business managers to determine, firsthand, their views on EA and S-D logic. A case study will be drawn to illustrate in details the various aspects of value integration in architectural decision-making. 9 CONCLUSION AND RECOMMENDATIONS In conclusion, this paper acknowledges the complexity in institutionalizing EA in any given organization. It is a process that requires an enormous investment in time, efforts and resources. Since resources are limited, architectural decisions must be carefully managed to ensure that it supports the larger business strategic context. This paper argued that S-D logic provides potential key ingredients for value creation in architectural decision-making. It capitalizes not only on the tangible organizational resources, but also on the productivity of the customers. Indeed, customers are the integrator in this continuing value integration process. Enterprise architects should therefore coproduce the values with the relevant customers in the overall architectural decision-making process by taking into consideration the appropriate value propositions, enhanced customer experiences, and aligned expectations. In this way, business managers are given the opportunity to take part in this continuing value creation process in EA and not simply act as a separate silo which is expected to appreciate the IT deliverables. The scope of this paper is limited and therefore it does not attempt a full exploration of the potential relationship between service science and EA. Further research to investigate the characteristics of EA environment and how that is formally structured to incorporate service science and, more specifically, S-D logic, is imminent. 10 ACKNOWLEDGEMENT The support of SAP Research CEC Pretoria and SAP Meraka UTD (CSIR) towards this research is hereby acknowledged. Opinions expressed and conclusions arrived at are those of the authors and not necessarily to be attributed to the companies mentioned in this acknowledgement. References Abe, T. (2005). What is service science? [Online]. Available: Armour, F.J. and Kaisler, S.H. and Liu, S.Y. (1999.) A big-picture look at Enterprise Architectures. IT Professional, 1(1), Boster, M. and Liu, S. and Thomas, R. (2000). Getting the most from your enterprise architecture. IT Professional, 2(4), Chuang, C. and van Loggerenberg, J. (2010). Challenges facing enterprise architects. In proceedings of the 43 rd Hawaii international conference on system sciences. Hawaii, United States. De Vries, M. and van Rensburg, A.C. (2008). Enterprise architecture - new business value perspectives. South African Journal of Industrial Engineering, 19(1), Espinosa, J. and Armour, F. and Boh, W. (2010). Coordination in enterprise architecting: an interview study. In proceedings of the 43 rd Hawaii international conference on system sciences. Hawaii, United States. Hsieh, Y. and Yuan, S. (2010). A S-D logic based approach to input-output analysis for technology spillover. In proceedings of 43 rd Hawaii international conference on system sciences. Hawaii, United States. 1272

12 Jonkers, H. et al. (2006). Enterprise architecture: Management tool and blueprint for the organisation. Information Systems Frontiers, 8(2), Kaisler, S. and Armour, F. and Valivullah, M. (2005). Enterprise architecting: critical problems. Proceedings of the 38th Hawaii International Conference on System Sciences. Kazman, R. and Asundi, J. and Klein, M. (2001). Quantifying the costs and benefits of architectural decisions. ICSE Proceedings of the 23rd International Conference on software engineering Lusch, R. and Vargo, S. and Wessels, G. (2008). Toward a conceptual foundation for service science: contributions from service-dominant logic. IBM systems journal, 47(1), Maglio, P. and Srinivasan, S. and Kreulen, J. and Spohrer, J. (2006). Service systems, service scientists, SSME, and innovation. Communications of ACM, July 2006, 49(7), van der Raadt, B. and Schouten, S. and van Vliet, H. (2008). Stakeholder perception of enterprise architecture. In 2nd European Conference on Software Architecture (ECSA). Springer, Ross, J. and Weill, P. and Robertson, D. (2006). Enterprise architecture as strategy: creating a foundation for business execution: Boston, Mass: Harvard Business School Press. Schekkerman, J. (2004). How to survive in the jungle of enterprise architecture frameworks: creating or choosing an enterprise architecture framework, Trafford Publishing. Shar, H. and Kourdi. M. (2007). Frameworks for enterprise architecture. IT Pro, September/October 2007, Spohrer, J. and Riecken, D. (2006). Introduction. Communications of ACM, July 2006, 49(7), p Spohrer, J. and Maglio, P. and Bailey, J. and Gruhl, D. (2007). Steps toward a science of service systems. Computer, January 2007, 40(1), Tyree, J. and Akerman, A. (2005). Architecture decisions: demystifying architecture. IEEE software, 22(2), Walsham, G. (1995). Interpretive case studies in IS research: nature and method. European Journal of information systems, 4(2), Zachman, J.A. (1997). Enterprise architecture: The issue of the century. Database Programming and Design, 10(3), Zimmermann, O. and Koehler, J. and Leymann, F. (2006). The role of architectural decisions in model-driven SOA construction. In the 21st international conference on object-oriented programming, systems, languages, and applications, Best Practices and Methodologies in Service- Oriented Architectures, Portland. Citeseer. 1273