Article Preview
TopIntroduction
In recent years, the literature has claimed that Service Oriented Architecture (SOA) is a better way to design and build enterprise-wide information systems (EWIS) (Krafzig, Banke, & Slama, 2005; Rosen, Lublinsky, Smith, & Balcer, 2008). SOA is a development paradigm which decomposes business functionality into a set of interoperable services that can be re-used in multiple EWIS across an organisation. Thus, a major goal of SOA is to maximise the reuse of existing services (Schepers, Iacob, & Van Eck, 2008; Müller et al., 2009) thus reducing both costs and development time for new application, and supporting business agility. Instances of services are also used to improve interoperability platforms between E-Government services (Santos & Madeira, 2010), B2B intermediaries in supply change (Pflugler, 2012) and virtual collaboration between organisations in cloud computing (Dollmann et al., 2011). Although potential benefits of SOA are frequently cited, the transformation of SOA into real benefits is difficult (Becker, Buxmann, & Widjaja, 2009). There is some debate on whether SOA should be adopted bottom-up, starting with few systems and expanding from there, or top-down, by effective control of SOA governance, with SOA becoming the dominant paradigm across the whole enterprise (Hau, Ebert, Hochstein, & Brenner, 2008; Marks, 2008; Rosen et al., 2008). Regardless of which approach is chosen, an organisation must adopt SOA across the whole enterprise i.e. Enterprise-wide SOA (ESOA) (Marks, 2008; Veger, 2008). In this study, ESOA is defined as both an architectural and development paradigm for building and implementing systems of systems, which are integrated on multiple levels (unit, component, system of systems) to support core business process and administrative areas of the entire enterprise (Sathish, Pan, & Raman, 2003; Ali, Petersen, & Mäntylä, 2012). ESOA adoption in this manner will produce a large-scale EWIS (Rosen et al., 2008) from loosely-coupled, interoperable components (services), to improve flexibility and reuse (Oh, Leong, Teo, & Ravichandran, 2007) of services.
However, organisational implementation of ESOA is still poorly understood (Luthria & Rabhi, 2008; Geric & Vrcek, 2009; Lee, Shim, & Kim, 2010). ESOA is much harder to implement than SOA because it assumes a willingness by units within the enterprise to share with other units those services that were developed for their own needs (Arsanjani, Zhang, Ellis, Allam, & Channabasavaiah, 2007). ESOA implementation also requires managers to agree on collective funding to support common service infrastructure (Becker et al., 2009). A Gartner study confirms that less than 25% of enterprises have the organisational maturity or technical skills to deliver ESOA, and blames inadequate SOA governance for many ESOA project failures (Müller et al., 2009).
To use ESOA effectively, enterprises need to identify and select appropriate services for sharing or reuse for the entire enterprise. Orchestration of multiple services to support a value chain across a federation of enterprises often requires collaboration and integration of cross-boundary platforms and multiple stakeholders (Brown & Carpenter, 2004). Some researchers recommend changing organisational structure in order to leverage the service concept. For example, Bieberstein, Bose, Walker, and Lynch (2005) argue for a flexible, agile enterprise structure based on core, team-based services to improve collaboration across business units. However, it would be difficult to implement such changes in the public sector where organisational structures are usually static and rigidly hierarchical (McAdam & Donaghy,1997).