MDM and SOa: Be WarneD!

Transcription

1 Issue December 2013LXXIX MDM and SOa: Be WarneD! BY Jürgen KreSS, BerthOlD Maier, hajo normann, rolf Scheuch, DanilO SchMieDel, guido SchMutz, BernD trops, clemens utschig-utschig, torsten WinterBerg unlock Your it with api Management by Mala ramakrishnan enterprise Mobile Services architecture: challenges and approaches by longji tang, Jing Dong, Wei-tek tsai $9.99USD $9.69CAD 6.99

2 Contents 3 From 5 the Editor MDM and SOA: Be Warned! by Jürgen Kress, Berthold Maier, Hajo Normann, Rolf Scheuch, Danilo Schmiedel, Guido Schmutz, Bernd Trops, Clemens Utschig-Utschig & Torsten Winterberg PUBLISHER Arcitura Education Inc. EDITOR Thomas Erl COPY EDITOR Maria Lee SUPERVISING PRODUCTION MANAGER Pamela Janice Yau 20 Unlock Your IT with API Management by Mala Ramakrishnan COVER DESIGN Sarah Turton WEB DESIGN Jasper Paladino Enterprise Mobile Service Architecture: Challenges and Approaches by Jing Dong, Longji Tang & Wei-Tek Tsai Contributors CONTRIBUTORS Jing Dong Jürgen Kress Berthold Maier Hajo Normann Andrzej Parkitny Mala Ramakrishnan Rolf Scheuch Danilo Schmiedel Guido Schmutz Longji Tang Bernd Trops Wei-Tek Tsai Clemens Utschig-Utschig Torsten Winterberg 2

3 From the Editor I m very pleased to announce Arcitura s new Big Data School, which will officially launch in just a few weeks, in January This new curriculum is dedicated to the practices, models, tools and architectures of modernday Big Data platforms and environments. The course modules are being developed based on the same conventions and standards used for SOA School and Cloud School courses, which allows them to act as a natural extension for those who have already studied or implemented SOA and/ or cloud computing environments. Thomas Erl 3

4 Arcitura Big Data School Vendor-Neutral Big Data Training & Certification 15 Course Modules 15 Exams 5 Certifications Course Modules 1, 2, 3 Now Available for Pre-Order Certified Big Data Science Professional Certified Big Data Analyst Certified Big Data Developer Certified Big Data Architect Certified Big Data Governance Specialist Module 1: Fundamental Big Data Module 2: Big Data Analysis & Technology Concepts Module 3: Big Data Analysis & Technology Lab Module 4: Fundamental Big Data Analysis & Science Module 5: Advanced Big Data Analysis & Science Module 6: Big Data Analysis & Science Lab Module 7: Fundamental Big Data Development Module 8: Advanced Big Data Development Module 9: Big Data Development Lab Module 10: Fundamental Big Data Architecture Module 11: Advanced Big Data Architecture Module 12: Big Data Architecture Lab Module 13: Fundamental Big Data Governance Module 14: Advanced Big Data Governance Module 15: Big Data Governance Lab Available January 2014

5 MDM and SOA: Be Warned! by Jürgen Kress, Oracle, Hajo Normann, Oracle ACE Director, Rolf Scheuch, Chief Digtial Officer, Opitz Consulting, Danilo Schmiedel, Senior Consultant, Opitz Consulting, Guido Schmutz, Technology Manager, Trivadis, Bernd Trops, Senior Principal Consultant, Talend Inc., Clemens Utschig-Utschig, Chief Architect, Shared Service Centre, Global Business Services, Boehringer Ingelheim, Torsten Winterberg, Business Developement and Innovation, Opitz Consulting, and Berthold Maier, Enterprise Architect, T-Systems International department of Telekom Germany Introduction You will waste your investment in SOA unless you have enterprise information that SOA can exploit. Gartner This quote from Gartner, Inc. describes the relationship between service-oriented architecture (SOA) and master data management (MDM) very vividly. An essential principle behind SOA is the reuse of components and the flexibility of using these components to support new functionalities or processes. MDM provides universal components (or services) for consistent data maintenance and distribution. Here the architecture concepts and principles of SOA run into MDM. This article begins by giving a brief motive for using MDM and a conceptualization. It will then go on to present typical variants for possible MDM architecture concepts, and illustrate the interplay of MDM and SOA with reference to the architecture pattern. Motive Increasing pressure from competition means that business models and underlying business processes have to be adapted in ever shorter cycles. At the same time, globalization and the digital networking of companies are making interaction with external business partners even more complex. Securely exchanging high-quality data is crucial for increasing efficiency in processes. This is where the central issue, the quality of information, and therefore its security in transactions, evaluations, and reports, all stem from. Once a company is no longer in a position to provide a consistent and consolidated view of its central business objects, implementing a company-wide policy for master data management becomes a good idea. Unfortunately, in many companies today it is common for IT systems to be unable to keep up with fast changes in organization, business, and even technology. As a result, on the companies side, a vast, ever-growing web of IT systems with known integration problems comes into being. This heterogeneity accounts for a variety of challenges when using master data that include differences in: data structures and formats in master data specifications and understanding of the master data values in the participating organizational units validations and plausibilities (data quality) processes and responsibilities concerning data sovereignty (data governance) business processes with partially conflicting functionalities in the application systems organizational units that have different systems for master data maintenance 5

6 The result of these problems is inconsistent information about underlying business objects, the master data. As we have already mentioned, data is essential input for all processes. If this source of information runs dry or costs for the interaction based on the data become too high, the value of the information becomes questionable and the company becomes faced with serious concerns. MDM on the business side and the SOA approach on the IT side can counteract this problem together. BARC s analysts assert: Over half of all IT experts believe data quality to be the biggest challenge. BARC goes on to say that 75 % of participants think master data management is the most important trend for their company [REF-1]. Conceptualization In general use of the IT language, there is a common, basic understanding of master data and its importance for the company and the IT systems concerned. Master data form the basis of all business activities in a company and its business processes. Master data describe the basic business objects of a company, and should therefore be considered as a company s virtual capital [REF-2]. In his presentation at the 7th Stuttgarter Softwaretechnik Forum in September 2011, Professor Dieter Spath even claimed that information, and therefore also the master data, should be considered assets similar to a company s equipment and be subject to asset management [REF-3]. MDM organizes how the master data is handled, something that every company needs in order to carry out its business processes. In the literature, there is a broad range of definitions for master data and master data management [REF-4] [REF-5] [REF-6]. This article uses the following definitions: Master Data Management Master Data Management (MDM) is management to ensure the quality of the master data. Its purpose is to guarantee that master data objects are suitable for use in all added value processes in the company. MDM includes all the necessary operative and controlling processes that encompass a quality-assured definition and guarantee that master data objects will be maintained and managed. In addition, MDM provides the IT components to map this process. MDM consequently assumes a supporting role, and its contribution to improving the added value takes place implicitly in two directions. The first is that data quality management continuously improves the data quality of master data and thereby the value of the information, with the second being the suitability of the master data objects for use in all core processes, in turn leading to improved added value through the optimized core processes. Master Data Object Master data objects are official, underlying business objects within the company that are used in the added value processes. A master data object describes the structure (blueprint) and the quality requirements (such as validations, permissible values within the structure). Talking with users, they frequently understand reference data (value lists) to be the actual master data of the company. A typical example is standardized value lists, such as ISO country codes and ISO currency codes. Master data use these lists as the foundation for forming groupings, hierarchy, and classifications. In this article, master data are not only reference lists but all official, underlying business objects. Procedure MDM is implemented, in-line with the definition, company-wide. For this to work, companies reassess the business processes and IT systems with regard to the changed use of the master data. Furthermore, the initiatives and projects of MDM itself are monitored and controlled via a management system. Finally, the strategy for the MDM is embedded into the general company strategy, and thereby contributes indirectly to 6

7 improving added value. The introduction of MDM and its sustainable operation is a business transformation [REF-7]. For this reason, MDM is not an IT project, but rather a development plan for business. IT provides an infrastructure for this business transformation and plays a part in the MDM development plan, although control and initiation should be conducted through business. Generally, reference frameworks are used for structuring and communicating complex correlations. The reference framework presented here structures the essential elements of the MDM development plan and subsequently serves as the framework for the procedure. The following explanations are based on business engineering, an approach that was developed by the Institute of Information Management at the University of St. Gallen for designing business transformations based on the strategic use of IT systems [REF-8]. Within its reference framework, business engineering considers three levels: the strategy, the organization, and the system architecture (data and applications). These areas have to be designed to successfully execute a business transformation in general, and therefore also within the framework (Figure 1) of the planning and performance of the MDM development plan [REF-9]. Figure 1 The reference framework for the MDM development plan. 7

8 MDM Strategy The instruments for formulating the vision and strategy are used in most cases to communicate and control medium or long-term development plans with organizational changes. The MDM team creates an overall concept or vision for organizing and managing MDM. This concept conveys the purpose of the MDM, explains the reasons for the change, outlines the goals, and describes guidelines for its use. It must be ensured that the MDM concept does not contradict the established company goals. The operationalization at an abstract level stems from this vision, through the formulation of the strategy with initiatives for the MDM. The strategy specifies the fields of activity and mirrors the wishes and ideals of specific decision-makers. In connection with the vision, the strategy describes the expectations of the future situation. Finally, as part of the MDM strategy, the road map and milestones are developed and initiatives for the accompanying change management are defined. MDM Organization The MDM development plan is a subject that embraces the whole company. MDM activities, processes, functionality, and structures must be coordinated across the different business areas of a company. To achieve this, the MDM requires a management system and process and structural organization to sustainably guarantee its success. The MDM requirements defined in the functional architecture form the basis for designing the process, structural organization, and the necessary IT support. The MDM management system operationalizes the development plan for the MDM strategy. It determines the point of departure for establishing the MDM, defines the processes and organization, and matches the assignment of key data to the processes. At the heart is the adaptation of the existing process organization required for use as part of the MDM. The standards and parameters associated with the master data must be integrated into the company s operating and recurring work cycles. On the one hand, this affects the operating core processes and their activities, which users perform as part of their line function or roles. On the other hand, MDM-specific administrative processes and data governance must be implemented to ensure operational capability and continuous improvements in how master data are used. A suitable structural organization forms the basis for processes. Employees are hierarchically included in the structural organization, according to their roles in the processes. This may be in their original line function or in a business reporting line, such as in the form of a matrix organization. The functional architecture structures the business requirements for the MDM, and acts as a basis for architecture decisions and the planning of necessary MDM processes and IT components. MDM System Architecture As a business transformation, MDM pursues the goal of implementing master data management across the company. To enable this at justifiable operating costs, IT must support the process. This applies, on the one hand, to the manually supported processes of the MDM itself, and, on the other, to the automated processes of data processing and distribution. For this, a clear system architecture that includes the interdependencies of the systems is necessary. The system architecture for the MDM describes both the current situation and the planned target architecture. If the enterprise architecture approaches are followed [REF-10], the following results are meaningful for the MDM development plan: an IT master plan for the MDM development plan, with focus on infrastructure 8

9 a map of master data with data models and data storage an overview of cross-company information flows (flow of values and commodities) a process map of operative processes that affect the MDM development plan and IT application systems required to support MDM The design areas include the application architecture with the necessary MDM-specific systems, supporting IT components, the integration architecture for master data logistics, and the underlying system infrastructure. The application systems and candidates for MDM are checked to ensure they provide the functionalities, and assessed with appropriate criteria. The application and integration components are based on an infrastructure platform that is considered separately from the infrastructure architecture. The information architecture performs a special role with MDM. The information architecture describes the master data objects, associations, and their attributes, in addition to cross-company information flows (flow of values and commodities). The importance of the MDM s data and metadata means that this must be anchored as a design area within the framework [REF-11]. The information architecture models support the other design areas: At a strategic level, the subject matter concerning the master data objects and domains to be considered are defined. At an organizational level, the information model describes the organizational relationships. The operative processes use master data objects and their attributes to define these dependencies. Furthermore, the information model also records the rules for validating master data and its quality criteria. On the organization side, organizational competence or responsibility for the master data segments is necessary for the DQM. At the system architecture level, the information model describes the physical data models that underlie the master data objects. These include, in connection with the integration architecture, the description of the data transformation and distribution processes. In the meantime, the organization and execution of an MDM development plan in the form of a program represents a best practice approach: Therefore the greatest challenges to success are not technical they are organizational. It is largely because of these issues that MDM should be considered as a program and not as a project or an application [REF-12]. From this point forward, this article limits itself to considering the system architecture and the technical aspects of using SOA and MDM. SOA & MDM An essential advantage to SOA is the loose coupling of the IT components. This promotes component reuse and makes it simpler and more flexible to use them to support new functionalities or processes [REF-13]. MDM should be based on service-oriented concepts and provide universal components (or services) for consistent data maintenance and retrieval of master data. Here the architecture concepts SOA are again incorporated into MDM. There are two different views supported by this claim: MDM Business Service reusable business logic for maintaining and validating master data MDM Information Service reusable information for use in the business processes 9

10 MDM Business Service Accessing master data objects such as products, customers, or business partners is necessary throughout all areas of the company, and thereby across the function and management areas: Their high reusability and the comparable ease with which standardization takes place mean that access to master data objects creates ideal service candidates. [REF-7 14]. This opinion is also held by the Masons of SOA, who regard accesses to master data objects as business entity services, and highlight that master data services amount to a considerable proportion of the developed services in SOA [REF-11 15]. A trend can also be detected here as well: The bundling of observed master data services into independent application domains anticipates the development of application architectures. In the future, central master data systems which offer services for accessing global master data objects will play an even more important role in application architectures [REF- 16]. Figure 2 demonstrates the transformation from uncontrolled to controlled management of master data: Figure 2 The transformation to controlled management of master data. This results in MDM becoming a fundamental component of SOA. Establishing an SOA in the company increases the frequency of the use of central master data services, and thereby implicitly their reuse. Establishing central, managed services for accessing and processing data is therefore a sensible next step. Performing a service decomposition leads to the discovery that, as part of the reusable services, services that undertake central tasks for managing the lifecycle of master data across the service domains are also required. In this context, typical difficulties with managing and maintaining the master data are also encountered at the data access level, even independently from an MDM development plan. They include: challenges with data protection and data security, depending on the lifecycle stage of data 10

11 problems with the standardized checking of the quality of master data performance issues with propagating data to subsystems In summary, the service-oriented concepts act as leverage for MDM through the: use of design principles (frameworks and patterns) from SOA when forming MDM business services to support MDM reuse of existing services to manage the lifecycle of master data use of enterprise service bus (ESB) concepts and infrastructure for push approaches when integrating and distributing the master data within the framework of master data logistics MDM Information Services Service decomposition requires central master data services. These support the secondary, more strategic approach to implementing an Information-as-a-Service (IaaS) [REF-17]. Figure 3 demonstrates their support of IaaS: Figure 3 MDM supports IaaS approaches. The underlying idea is very simple. A facade which delegates access to the IaaS is used so that single applications or services do not have to individually implement access to the data. This can be considered as a virtualization of data access, as the data sources are now transparent at the layer to be accessed. This provides central control over the typical CRUD operations on the required master data. Control over validations is now guaranteed, and any inconsistencies in the maintenance of different applications and services are resolved. If this approach is taken as part of MDM, the three underlying challenges related to the information-as-aservice (IaaS) approach can be managed through technical and organizational measures. From the consumer s point of view, this means: Definition The meaning (semantics) of master data and their attributes must be implemented uniformly and 11

12 consistently. This also includes the availability of the definition and its uniqueness. Quality Checks of the data quality can now be performed on a virtualized platform with complete transparency for the consumer, who can change the master data. The IaaS repository secures common semantics and a system of rules for the validation. This also prevents inconsistencies. Governance The final point is IaaS services lifecycle management. This can be directly covered through the established governance approach for the management of services in the SOA environment. In Table 1, the central services of MDM are contrasted with the eight factors that determine master data value: Factor Explanation MDM Central Service Quality Guarantee of the required data quality Data quality management Consistency Guarantee of consistent semantics in structured and unstructured information Metadata management, hierarchy management Security Stability Granularity Secure handling of internal and external (from business partners, customers) data Management of the version control and variants of the data for outdated and longrunning processes Management of information at all levels of granularity through structures Use of central services for authorization and authentication Routines for maintaining master data and its versioning/history Metadata management, hierarchy management Currentness Guarantee of up-to-date master data Routines for maintaining and distributing master data and its versioning/history Context Dependency Origin Guarantee of consistent semantics in structured or unstructured information Management/tracking of origin and distribution of master data Table 1 MDM central services are contrasted against the eight factors. Metadata management, hierarchy management Metadata management This eliminates the two problems that are typically encountered when managing heterogeneous master data in different applications that have varying functionalities and decreasing data quality: Inconsistencies when retrieving the same master data for different services or applications are avoided. Inconsistencies when validating and checking data are avoided. Data Storage Architecture Pattern The type of architecture that is selected for data storage has a far-reaching impact on MDM. There are two main approaches for storing and managing master data [REF-18]: System of Reference central directory with decentralized data storage System of Record central data storage with a SPoT 12

13 SPoT stands for Single Point of Truth, which is sometimes referred to as a golden record [REF-19]. Ultimately it means the existence of a unique, valid master data object. However, both approaches seldom exist in a pure form in practice. They are more likely to be used in combination with other technologies. In this respect, systematization occurs as is demonstrated in Figure 4, in three different approaches to data storage: Centralization MDM with a central database or central business applications Registry MDM with distributed data and a central directory Coexistence MDM with a hybrid approach with the coexistence of different data sources Figure 4 The underlying architecture pattern for MDM. Centralization In this architecture pattern, master data is maintained through one or several of the leading business applications for master data. Here, an MDM solution that is implemented as something of an independent, central application, should also be understood as a managing business application. The global master data, the guarantee of the master data quality, and the processes for maintenance are determined through the managing business applications. Master data is propagated to the various, mostly local, applications by a system for master data logistics. This guarantees that the master data remains consistent. This approach is widespread in practice, and allows for centralized control which standardizes the master data company-wide. The data is consistently changed through one or more business applications, and underlies the identical master data quality management or methods for guaranteeing quality. The approach of consolidating master data on a platform that is so frequently described in literature corresponds to this approach, whereby the managing application in this case corresponds to the data management process. The master data model is harmonized, as it is central. This approach is extremely 13

14 good for company units that can agree jointly on global master data. The definition of a SPoT is through the managing system or the central database. Registry This approach assumes a high level of autonomy for the different system worlds, and decentralized implementation. As with database systems that are based on the inverted lists principle, there is a central list with references ( registry ) which are required for the unique identification of a master data object specification. The actual pieces of information (master data values) are distributed between the different systems. In this concept, reading master data is connected to a high network load per retrieval instance, and is therefore recommended more for MDM approaches that provide a low degree of overall master data views. A central problem can occur in this approach, in the area of data quality management. Since the information is managed and stored in the decentralized systems, distributed governance is needed. This circumstance almost inevitably leads to greater autonomy for the distributed units and a decline in centralized control. Only the consistency of the attributes for identification has to be guaranteed to be standardized through all closed systems. Coexistence One weakness of the registry-based approach is the high network load. One weakness of the centralized approach is the centralization of the functionality through managing business applications. A decentralized approach which follows federal principles and permits coexistence with the existing systems allows these weaknesses to be counterbalanced. It resembles the master/master and master/slave relationships with replications in a database. In this case, local copies in the distributed MDM systems are also provided and reconciled using master data distribution logistics. The copies and replications can thereby be subtly adjusted to the necessary degree. As with the registry approach, DQM takes place locally but with global starting points, as all relevant data are kept in the master in the middle (similar to the consolidated approach). The weak points of this concept are already known from the replication environments. There are problems with control through successful handshaking as well as with the restart points during interruptions. The security of the data in the network cluster is also not sufficiently guaranteed. From our point of view, this approach requires a considerable number of interventions in the existing infrastructure. Scenarios for Use The use of SOA approaches will now be considered in light of the different architecture patterns, with different scenarios for use discussed individually. Centralization The SOA leverages are lowest for this architecture approach. Data management is through a business application that is often encapsulated. This application indicates the necessary processes for maintaining the master data and contains the routines for guaranteeing data quality. Data distribution mostly takes place as an ETL process, or as the conventional and established EAI approaches (Table 2). 14

15 Criteria Data Responsibility Data Storage / Redundancy Specifications of Centralization Architecture Pattern The process and structural organization of the individuals responsible for data quality can be organized in any way. However, responsibility for updating data is borne by the managing business application Using copied data makes redundancy high, whereby the distribution and administration is governed by clear responsibility. Redundancies within the central master dataset should be low Data Distribution Unidirectional distribution in the direction of local business applications from the dataset of the managing system Central control of distribution Data Consistency & Harmonization Data Currentness & Availability Integration Data Access Relevance of the SOA Both the central dataset and the business applications are consistent Harmonization is very high, as it is central Availability for read access is very high, as all systems can access the central dataset Currentness can be adjusted optimally using the master data logistics, although it is mostly batch-oriented Integration falls back on state-of-the-art data integration approaches from the BI/DWH environment, and is robust Access is only read through the local business applications, and only managing business applications can change master data Medium to low The managing business applications that use master data jointly should function with a standardized business logic. Here, SOA MDM services can be used to good effect In practice, this approach is implemented through standard solutions from the developer, with the result that their system architecture is vital Use Scenario Robust approach for ERP/CRM centralized approaches Platform or staging area for BI/DWH solutions Implementation of managing business applications, particularly when using standard software Advantages Clear and robust technologies used Secure master data for further processing Disadvantages Heavy limitation and dependence on the managing business applications Distributed processing of global master data through different systems is not supported Table 2 The specifications of the Centralization architecture pattern. Registry Using SOA is vitally important with this architecture approach (Table 3). The propagation of master data is in a distributed environment, and generally uses the transaction or dataset-oriented procedure for propagating changes here. To display the information, different services need to be activated through the network. These services read the information that belongs to the identifying data from the registry in the specific operational systems. This data then arrives back at the starting point via the network, where the read data is compiled into a master dataset. 15

16 An integration procedure based on loose coupling offers advantages here. Each change to the structure or to a version of the master data from the local systems must be reported to the central registry in a similar manner. Criteria Data Responsibility Data Storage / Redundancy Data Distribution Data Consistency & Harmonization Data Currentness Integration Data Access SOA Relevance Specifications of Registry Architecture Pattern Remains completely local except for the governance concerning the attributes for identification Very low, and limited to the values for identification Not necessary (except for the global attributes for identification) Not necessary (except for the global attributes for identification) Very high through the realtime reading access Crucial Not possible without integration platform, and therefore a real necessity for a stable and robust distribution. Mostly optimized for reading operations which take place in a distributed system Access to the attributes is always through the directory as a switchpoint for access Very high Identification and compilation of the master data is through a centralized and shared access layer. This uses the specific adapter for the connected applications in a transparent manner Use Scenario Large distributed amount of master data with local autonomy (in some circumstances, due to legal constraints, see also data protection (DBSG)) Exchange platforms for a joint e-commerce marketplace Advantages Simple form of implementation for infrequent need for Web access Disadvantages High network load and extremely time-consuming governance for the DQ due to local autonomy Guaranteeing data consistency is problematic Table 3 The specifications of the Registry architecture pattern. Coexistence The use of SOA is essential for this architecture approach as well (Table 4). Data storage is in distributed systems and also in distributed data storage. Consequently, the maintenance and management of master data takes place in a distributed environment, and each system starts the propagation of master data logistics. Replication itself can take place asynchronously or synchronously to enable different approaches even in the SOA on the side of implementing the replication, including conflict resolution (similar to the registry approach ). 16

17 Criteria Data Responsibility Data Storage / Redundancy Data Distribution Data Consistency & Harmonization Data Currentness & Availability Integration Data Access Specifications of Coexistence Architecture Pattern Partially global and therefore under central responsibility, but also a high degree of local autonomy The master data globally required is available redundantly, as the calibrated node ultimately acts as a central data hub Bidirectional distribution of master data with all the problems of a master-master or master-slave replication in distributed systems Data consistency and harmonization primarily depend on the business logic of the different business applications. The centralized DQ has the right to change the local data. This can lead to consistency problems in the business applications in question High, as the business applications only access their datasets Costly and complex, as the essential load is on the master data logistics that have to distribute the master data to the different systems There is no direct access to the calibrated node. Instead, the systems work on the local updated datasets SOA Relevance High Overall routines for checking the master data quality must be created, including tools for the data stewards. Moreover, the master data logistics use the MDM services for the CRUD operations for replication Use Scenario The implementation of the central solution is not possible with local autonomy. The calibrated node serves as a transition to a central solution with managing systems or to the transaction server approach Advantages Local autonomy is optimally connected with centralized master data management Disadvantages High degree of complexity for master data logistics, and stringent governance to secure a uniform system of rules in the business application Table 4 The specifications of the Coexistence architecture pattern. Conclusion In conclusion, the question still remains as to whether you could pursue a consistent SOA approach without any MDM. Andrew White and Jon Radcliffe (Gartner, 2010) believe that is not possible. In their opinion, the success of SOA projects stands and falls with the use of MDM: Through 2011, 70% of SOA projects in complex, heterogeneous environments will fail to yield expected business results benefits unless MDM is included. We will close with that judgment. Takeaways An MDM initiative is performed by business and IT together, with the responsibility lying with business. The MDM endeavor should be viewed as a program, not a project. A clear data sovereignty definition, data structures, and the required maintenance processes for data quality 17

18 are the foundation for success. The use of a reference architecture makes introducing and maintaining MDM systems easier. SOA will only achieve the desired results in combination with MDM. The reference architecture should be independent from the technology chosen. References [REF-1] BARC: Data Warehousing 211 Status Quo, Herausforderungen und Nutzen, White Paper, BARC Institut, p. 28, Würzburg, July p. 28, 35 [REF-2] M. Kaufman: Master Data Management [REF-3] D. Spath: Unternehmensgut: Stammdaten in the conference transcript from the Stuttgarter Softwaretechnik Forums 2011, Stuttgart, Frauenhofer Verlag, p. 29 [REF-4] A. Berson, L. Dubov: Master Data Management and Customer Data Integration for a Global Enterprise, McGraw Hill, 2007 [REF-5] A. Dreibelbis, E. Hechler, I. Milman, M. Oberhofer, P. Van Run, D. Wolfson: Enterprise Master Data Management: An SOA Approach to Managing Core Information, 2008, IBM Press. p. 23 [REF-6] B. Otto: Funktionsarchitektur für Unternehmensweites Stammdatenmanagement, Bericht Nr.: BE HSG/CC CDQ / 14, Institute of Information Management at the University of St. Gallen, 2009 [REF-7] J. W. Schemm: Zwischenbetriebliches Stammdatenmanagement, Springer, p. 79 et seq. [REF-8] H. Österle, R. Winter, F. Höning, S. Kurpjuweit, P. Osl: Business Engineering: Core-Business- Metamodell, in: WISU Das Wirtschaftsstudium, 2007 REF-9] B. Otto: Funktionsarchitektur für Unternehmensweites Stammdatenmanagement, Bericht Nr.: BE HSG/CC CDQ / 14, Institute of Information Management at the University of St. Gallen, p. 14 [REF-10] Staehler et al.: Enterprise Architecture, BPM und SOA für Business-Analysten, Hanser, 2009 [REF-11] J. W. Schemm: Zwischenbetriebliches Stammdatenmanagement, Springer, p. 79 et seq. [REF-12] M. Kaufman: Master Data Management. p. 16 [REF-13] T. Erl: SOA Design Patterns, Prentice Hall Service-Oriented Computing Series. p [REF-14] J. W. Schemm: Zwischenbetriebliches Stammdatenmanagement, Springer, p. 223 [REF-15] B. Maier, H. Naumann, B. Trops, C. Utschig-Utschig, T. Winterberg: SOA Spezial Ready for Change, Software und Support Verlag, p. 35 et seq. [REF-16] J. W. Schemm: Zwischenbetriebliches Stammdatenmanagement, Springer, p. 223 [REF-17] Allen Dreibelbis, Eberhard Hechler, Ivan Milman, Martin Oberhofer, Paul Van Run, Dan Wolfson: Enterprise Master Data Management, An SOA Approach to Managing Core Information, 2008, IBM Press. p. 86 et seq. [REF-18] A. Dreibelbis, E. Hechler, I. Milman, M. Oberhofer, P. Van Run, D. Wolfson: Enterprise Master Data Management, An SOA Approach to Managing Core Information, 2008, IBM Press. p. 23 [REF-19] M. Kaufman: Master Data Management 18

19 New Cloud Virtualization Specialist Certification Arcitura Education Inc. has announced a new certification for the Cloud Certified Professional (CCP) program from CloudSchool.com, dedication to cloud computing-based virtualization technology and practices. The new Certified Cloud Virtualization Specialist designation requires the completion of Prometric exams C90.01, C90.02, C90.16, C90.17, and C This certification track correspondingly introduces three new CCP courses and self-study kits. CloudSchool.com CLOUD CERTIFIED Virtualization Specialist Workshops & Self-Study Kits Bundles Now Available For Pre-Order! Attend an instructor-led workshop or purchase the official Cloud Virtualization Specialists Certification Self-Study Kit bundle. CCP Module 16: Fundamental Cloud Virtualization Core topic areas pertaining to the fundamental virtualization mechanisms and types used within contemporary cloud computing platforms. CCP Module 17: Advanced Cloud Virtualization A range of specialized and advanced topics that build upon module 16 to explore virtualization-related reliability, performance and integration, as well as combinations of mechanisms. CCP Module 18: Cloud Virtualization Lab A hands-on lab during which participants apply the models, concepts, and techniques covered in previous courses, in order to complete a series of complex exercises. Arcitura

20 Unlock Your IT with API Management by Mala Ramakrishnan, Director of Product Marketing, Oracle Abstract: Application Programming Interface (API) management is a newly defined space that is shaping the multi-channel strategy of enterprises across organizational boundaries. In this byline, Oracle s Mala Ramakrishnan will look at a comprehensive API management solution that helps organizations develop welldesigned infrastructure that securely exposes APIs all the way to managing the front-end for adoption. The article will also touch on how organizations can outsource application enhancement by empowering developers through API adoption, as well as add a mobile front to applications to capture new revenue opportunities. Finally, the piece will examine how organizations can streamline business and IT objectives by managing the lifecycle of their APIs. Introduction We are at the beginning of an era during which a new wave of innovation is completely changing IT priorities. Mobility and globalization across organizational boundaries are driving this innovation. The definition, growth and quick adoption of Application Programming Interface (API) management is a direct result of the booming mobile frontier and globalization. API management extends application development beyond organizational boundaries and drives innovation, extends applications and increases adoption across various channels and devices, driving new revenue streams. API management provides the potential to selectively expose applications through APIs and manage all aspects from realizing business value and security to fostering a developer community. What are APIs? While API management is a new space, APIs are a tried and tested concept in software. APIs are used to encapsulate complexity in applications and selectively expose functionality so developers can build new solutions that leverage APIs. For example, a Web crawling company could expose APIs to a maps database that gets updated in real time. Third parties can then build out location-based applications and focus on the services they provide while leveraging the content of the exposed APIs for location relevancy. Exposing APIs has gained traction as organizations realize that leveraging content across boundaries creates more innovation that drives value to all stakeholders. It creates a win-win situation for the enterprises that expose the APIs, the consumers of the APIs, and the end users. Often the most innovative use of APIs comes from outside the organization from customers, partners and third parties. Monetization of APIs Identifying which parts of your application to expose as APIs is just one aspect. The bigger and more important issue is the development of a sound business strategy around your APIs. It is one thing to expose APIs, and another to actually generate revenue from the APIs, ensure widespread adoption and scale the application to match the needs of the APIs. Organizations are looking to API management to quickly expose their valuable IT assets and monetize them through multiple channels. API management begins with developing a strategy to identify what IT assets can be exposed externally to tap into new revenue streams and increase brand awareness. There are two approaches when developing this strategy content and capability. 20

21 Content Based Monetization of APIs Organizations may choose to share content that is specific and unique externally. This approach is appropriate when one of the following is true: Content is valuable when organizations create high-value content this approach may be the best choice. For example, media companies generating news or life sciences companies with research results that consumers are willing to pay to access. The company that owns the data can choose to expose APIs through which the data can be accessed. Consumers of the API may leverage this data in their own applications. A subscription model or collecting royalties to leverage the data are ways to monetize this strategy. Good will when organizations want to help the public, they may choose this model and give the content away for free. A city may choose to publish an updated list of available parking through an API. Third parties can then leverage the API to build applications on mobile devices so drivers can quickly find parking spots. The resulting increase in parking fees can bring in more revenue. Fewer parking violations and the convenience of finding parking will drive more citizens to visit the city. The city gains indirectly as local businesses flourish from the better citizen experience. Content as a means to deliver capability organizations may choose to give content away for free where it serves as the means to bring customers to their door to drive revenue opportunities. For example, a coffee chain could offer, at no charge, an API which provides store location information for developers to utilize in a mobile application. That way, when a person wants coffee, they find a convenient location. This drives incremental revenues as customers are able to find a location closest to where they are currently. Capability Based Monetization of APIs This method is usually chosen by organizations when they have a capability that can be delivered via a browser or a mobile application and actively drive new revenue opportunities. This could be to expose existing services via these new channels. For example, offering APIs which allow developers to create a mobiledevice friendly retail store may bring in more purchases from shoppers on the go, who are not sitting in front of a computer with a Web browser. Another approach is making APIs available that can be leveraged by third parties to create innovative new offerings combining core capabilities with other Web-based content or capabilities. This can positively alter the consumer experience and result in increased revenue. In general, the IT assets an organization chooses to expose can be a means to an end or it can be the end in itself, and some offerings may certainly be a combination of both content and capability. For example, a vendor may make it possible to look up images of objects and do a price lookup for free and then link to different vendors for purchase. API Management for Mobile Enablement There are two ways to develop an enterprise mobile strategy -- controlling the end-to-end integration experience from the enterprise to the handheld, or exposing enterprise assets through APIs for third parties to build out mobile solutions. Security, management, and runtime enablement are all key aspects that serve as the solution for mobile service enablement. API management controls APIs internally, but it involves a bit more to actually manage the APIs externally as assets that are available for consumption. It involves managing the external lifecycle of the APIs, ensuring adoption and fostering a developer community among third parties. 21

22 Mobile App What do you want to offer? API Mobile Service Enablement: Control end-toendexperience of mobile application from back-office to mobile front-end API Management: Expose IT assets as APIs to external mobile application developers API management is an innovative approach to mobile enablement that has recently seen high adoption. With API management, organizations expose existing IT assets and services as APIs, which can be leveraged by third parties. This allows mobile application developers external to the organization to tap into innovation and capture new revenue opportunities. It allows for differentiated customer service as third parties may combine disparate APIs from different vendors to provide innovative solutions that would not be possible otherwise. Requirements of API Management API management is all about managing the exposure and adoption of APIs. Exposing the APIs externally requires the infrastructure to be well designed and service-oriented, hiding the underlying complexity from the end user and exposing exactly what is needed for consumption. Security, usability, throughput and availability of the APIs can determine the success of the API adoption. It requires that the protocols of communication be easy to leverage and universally accepted across devices. API management should provide the means to measurably analyze the business gains in increasing the bottom-line revenue. It should improve brand awareness and quantify developer adoption. Lastly, it needs to speak the language of the developers and foster community building by delivering on trust and collaboration. API management exposes and manages specific functionality in applications in a secure manner. It provides end-to-end lifecycle management of APIs. Through a centralized repository, policy enforcement and tracking of key performance indicators, the solution provides the foundation required to build business value. A Day in the Life of an API An API is a valuable asset which, when put into the hands of partners and creative mobile application developers, has the potential to drive business value. API management allows organizations to realize the value of these assets by unlocking their potential. It flattens the world of IT operations and removes boundaries to include external participation, providing an opportunity for unprecedented collaboration across products and services. This harnesses previously unknown or under-developed customer opportunities and ultimately delivers new revenue streams. It can raise the bar for innovation and put a front end on an organization s enterprise across different mobile devices and channels. It has the power to transform an enterprise by scaling developers and consumers without traditional organizational limits. However, API management entails a lot more than just solving the last mile access challenge to an asset. To truly leverage the value of these traditionally private assets across all of the modern channels and to ensure long-term sustainability and business value, it is imperative to consider the underlying issues that need to 22

23 be addressed by API management. There are two lifecycles to consider when exposing a business asset for external consumption internal and external. Internal Lifecycle of an API The first lifecycle is the way that business assets are built out and managed. For any application especially when the audience is an unknown third party high availability, throughput and reliability of the asset have to be guaranteed. In addition, the organization may choose to scale out and offer more APIs, in which case, reuse and the elimination of duplication becomes important. As the organization matures, the underlying infrastructure of the business asset needs to change while requiring zero down time from the API. Decommissioning an API is another aspect that needs to be considered, when the business decides to replace an existing API or expand functionality or decide to close it down. Exposing the APIs requires the internal infrastructure to be well designed and service-oriented, hiding the underlying complexity from the end user and exposing exactly what is needed for consumption. It requires tools that encourage collaboration and teamwork that is necessary to create the assets. External Lifecycle of an API To succeed with exposing an API externally, several factors need to be considered. Security of the business assets is the first concern, as the external consumers may be developers from any organization customers, partners or third parties wishing to leverage an organization s APIs. The protocols of communication, though universally accepted across different channels, are still very new and not yet necessarily standardized. It can be frustrating for the consumers of the API, especially if the service does not match expectations in terms of how the API handles security or errors, and as a result, the adoption of the API may suffer. In addition, if the consumer of an API chooses to consume from more than one API source, this lack of standardization is compounded. As a result, APIs require meaningful documentation, best practices, samples, continuous support and communication among users. API management needs to deliver on all this and, in addition, a trust and collaboration-based developer community needs to be fostered so there can be an exchange of ideas, support and innovation. API management should allow cross-company collaboration and allow setting and management of access rights. API management should provide the means to analyze business gains in increasing top-line revenue when required. API management should also assist in defining and analyzing key performance metrics and feedback into improving the APIs. It should justify improving brand awareness and quantify developer and consumer adoption. API Management: a New Front for SOA Service Oriented Architecture (SOA) or service integration has matured, delivering on the promise to streamline business processes, lower costs and improve efficiency by breaking down monolithic infrastructure into services for reuse. API management is fundamentally SOA with a difference in approach of extensive involvement of unknown third party users and a focus on channel strategy and in particular, mobile enablement. It would be an oversight not to leverage the value that a mature technology brings to bear and to re-invent the service integration wheel as API management. While a lot of API management vendors focus on just the external lifecycle management of the APIs, service integration typically encompasses the entire internal and external lifecycles of the API, ensuring guaranteed success for API adoption and channel strategy. A quick look at a few core components of a typical service integration offering shows that they are necessary aspects of API management. 23

24 Mediation and Virtualization Typically delivered by a service bus, mediation and virtualization guarantee that functionality under the covers of an API can change and grow independent of the definition of APIs. An analogy would be an electrical outlet would it matter to a light bulb whether the source of electricity behind the scenes was switched from one power plant to another? Similarly for the consumers of an API, it should not matter what the underlying functionality is. The API should just meet the contract without having to reveal the underlying implementation, and should guarantee delivery. Orchestration and Connectivity Delivering an API involves orchestrating across functionality both internal and externally. This requires not just a good orchestration engine and tool, but also availability of an extensive set of adapters that can ensure connection across a myriad of applications that usually encompass any IT infrastructure. In addition, it requires that the API will deliver on guaranteed performance, high availability, reliability and scalability all easy to achieve with a tried and tested service integration offering. Governance This is a key component typically layered on top of service integration that ensures delivery on key performance metrics and helps with API adoption and maintenance including aspects such as documentation, version control and delivery of business processes for the management of APIs, across different personas both within and external to the organization. It can help ensure iterative measurement of the success of APIs and delivers on continuous improvement. It is one thing to plan a business strategy for monetization around APIs and another to measurably track the monetization and adoption something service integration has delivered on for decades. 24

25 Cloud Computing Concepts, Technology & Architecture This is a great book on the topic of cloud computing. Kapil Bakshi, Architecture and Strategy, Cisco Systems Inc. We will recommend this book to Oracle customers, partners, and users for their journey toward cloud computing. Jürgen Kress, Fusion Middleware Partner Adoption, Oracle EMEA A cloud computing book that will stand out and survive the test of time. I highly recommend this book Christoph Schittko, Principal Technology Strategist, Microsoft Corp. a must-read for any IT professional interested in cloud computing. Andre Tost, Senior Technical Staff Member, IBM Software Group The Cloud Computing: Concepts, Technology & Architecture text book will be released on May 16, This is the ninth title in the Prentice Hall Service Technology Series from Thomas Erl. The book is authored by Thomas Erl, Zaigham Mahmood and Ricardo Puttini. To learn more about this book, visit: TABLE OF CONTENTS Chapter 1: Introduction Chapter 2: Case Study Background PART I: FUNDAMENTAL CLOUD COMPUTING Chapter 3: Understanding Cloud Computing Chapter 4: Fundamental Concepts and Models Chapter 5: Cloud-Enabling Technology Chapter 6: Fundamental Cloud Security PART II: CLOUD COMPUTING MECHANISMS Chapter 7: Cloud Infrastructure Mechanisms Chapter 8: Specialized Cloud Mechanisms Chapter 9: Cloud Management Mechanisms Chapter 10: Cloud Security Mechanisms PART III: CLOUD COMPUTING ARCHITECTURE Chapter 11: Fundamental Cloud Architectures Chapter 12: Advanced Cloud Architectures Chapter 13: Specialized Cloud Architectures PART IV: WORKING WITH CLOUDS Chapter 14: Cloud Delivery Model Considerations Chapter 15: Cost Metrics and Pricing Models Chapter 16: Service Quality Metrics and SLAs PART V: APPENDICES Appendix A: Case Study Conclusions Appendix B: Industry Standards Organizations Appendix C: Mapping Mechanisms to Characteristics Appendix D: Data Center Facilities (TIA-942) Appendix E: Emerging Technologies Appendix F: Cloud Provisioning Contracts Appendix G: Cloud Business Case Template

26 Cloud Architect Certification Self-Study Kit Bundles Now Available and Shipping Worldwide CloudSchool.com CLOUD CERTIFIED Architect Arcitura the IT education company

27 Enterprise Mobile Service Architecture: Challenges and Approaches by Jing Dong, University of Texas, Longji Tang, FedEx and Wei-Tek Tsai, Vice Chair of AZ-TW Society of Technology Abstract: Today, enterprise systems are integrated across wired and wireless networks. Enterprise Mobile Service Computing (EMSC) is a recent development in distributed computing, and Enterprise Mobile Service Architecture (EMSA) is a new enterprise architectural approach for mobile system integration. This chapter introduces the concepts of EMSC, discusses the opportunities, and addresses mobile constraints and challenges in EMSC. The mobile constraints include aspects relating to mobile hardware, software, networking, and mobility. Many issues such as availability, performance, and security, are encountered due to these constraints. To address these challenges in EMSC, the chapter proposes seven architectural views: Enterprise Mobile Service, Enterprise Mobile Service Consumer, Enterprise Mobile Service Data, Enterprise Mobile Service Process, Enterprise Mobile Service Infrastructure, Enterprise Mobile Service Management, and Enterprise Mobile Service Quality. Each is described with principles, design constraints, and emerging technologies. In order to illustrate a practical implementation of EMSA, the chapter presents a major shipping and delivery services enterprise as a case study to describe the integration of service-driven mobile systems in the enterprise. Introduction In a service-oriented enterprise architecture [REF-1][REF-2] there are two major components services and service consumers. Traditionally, end service consumers access the system mainly through personal computers (PCs), such as desktops and laptops (notebooks) in an end-to-end system. With development of wireless communication and technologies, such as 3G and 4G [REF-3][REF-4],, mobile and non-pc devices (tablets and others), such as iphone, ipad, ipod, and Android-based mobile devices are overtaking PCs as the most widely used communication and Internet access devices. Canalys reported that 488 million smart phones were shipped in 2011, compared to 415 million client PCs that were shipped by vendors in its report Smart phones overtake client PCs in 2011 [REF-5]. Moreover a recent IDC report revealed that PCs will slip in market share from 35.9% in 2011 to 25.1% in 2016, as Android-based devices will grow from 29.4% share in 2011 to become a market leader in 2016 with 31.1% share. Devices running ios will grow from 14.6% to 17.3% market share by 2016 [REF-6]. Mobile devices are becoming the major interface for consuming services that are not limited to general phone services, but also include , internet, entertainment, and social media services. Recently, use of enterprise services, such as mobile search, mobile ecommerce (M-commerce) [REF-3] - shopping and shipping, and mobile payment, from mobile devices are growing rapidly. Enterprise mobile computing began from first-generation smart phones such as IBM Simon Personal Communicator, the first smartphone released in 1993 (Esposito, 2012). The IBM Simon had a simple operating system called DatalightROM-DOS, 16 MHz CPU, 1 MB RAM and 1 MB storage. Its features included sending and receiving facsimiles, s and cellular pages. It also included many applications including an address book, calendar, appointment scheduler, calculator, world time clock, electronic note pad, handwritten annotations and standard and predictive touchscreen keyboards. Around the same time, there were significant developments in Europe and Asia too. For example, Nokia N9000 Communicator came to the market in 1996 and offered pretty much the features that IBM Simon offered but had a mechanical keyboard instead of the 27

28 touchscreen keyboard. Many generations of communicators followed. The first Symbian smart phone was Nokia N9210 in These devices were based on the Symbian OS that was a multitasking OS, supported video capturing and viewing, had browsers, navigation software, clients, etc. Several handsets from Korea and Japan also came to the market that used Symbian OS since The first generation mobile devices also included Palm Treo 600, and first generation Blackberry, etc. The modern era of Enterprise mobile service computing started with the release of the Apple iphone in the summer of 2007 [REF-7]. The iphone defined a new generation of smart phones. Smart mobile devices, such as Apple iphone, Google Android devices, Microsoft Windows 7 and Windows 8 smart phones, have a multitasking operating system, a full desktop browser, Wireless LAN (WLAN, also known as Wi-Fi) and 3G/4G connections, a music player, and supported several of the following features (Firtman, 2010): Mobile Web, GPS (Global Positioning System) or A-GPS (Assisted GPS), Digital compass, Video-capable camera, Bluetooth, Touch and gesture support that allowed an user to touch a screen or make a movement to issue commands, 3D video acceleration, and Accelerometer [REF-8]. The features and capabilities of modern smart phones and smart mobile devices (including tablets, ipad, and ipod) provide a portable channel to connect to enterprise services through mobile applications and web interfaces. The mobile channel is regarded as an extension of the Internet and the enterprise network. Mobile computing has been growing at a staggering rate across the developed nations. The following Table 1 shows the mobile subscription trend. Although not all mobile subscribers perform mobile computing, specifically in developing countries, the dramatic growth of mobile data plan and internet plan subscriptions in developed countries shows that demand of mobile computing is greatly increasing. Mobile cellular Subscriptions (millions) Global Developed Nations Developing Nations The Americas Per 100 people 86.7% 117.8% 78.8% 103.3% Fixed telephone lines (millions) Per 100 people 16.6% 39.8% % Active mobile broadband subscriptions (millions) Per 100 people 17.0% 56.5% 8.5% 30.5% Fixed mobile broadband subscriptions (millions) Per 100 people 8.5% 25.7% 4.8% 15.5% Table 1 - Global Mobile Subscriptions in 2011 [REF-9]. Mobile computing is expected to continue its spectacular growth rate over the next five years.portio Research predicts that mobile subscribers worldwide will reach 6.5 billion by the end of 2012, 6.9 billion by the end of 2013, and 8 billion by the end of 2016 [REF-9]. 28

29 Erickson forecasts that mobile subscriptions will reach 9 billion in 2017, of which 5 billion will be mobile broadband connections [REF-9]. The trend of continuous mobile growth is changing the enterprise business customer space as shown in Figure 1: Figure 1 - Extending Enterprise Customer Space to Mobile User Space. At the same time, this trend is greatly increasing the demands of mobile applications and mobile services. Each time a mobile ad is displayed it creates what is termed an impression. Compared to 2010, total impressions per user on mobile apps in November of 2011 grew 122%, in which shopping and services increased 105% [REF-10]. The widespread mobile consumer adoption creates a new communication and commerce channel for enterprises, such as mobile sales and services (e.g. shopping and shipping), mobile payments and account access, customer self-services, customer incident reporting, notification and recalls, customer relationship management (CRM), and remote asset monitoring and control including real-time security alerts. To meet this increasing demand for mobile commerce and services, service providers and enterprises are building and improving their mobile infrastructure, applications, and services constantly. The developing trends are not only impacting the business models of the enterprise, but also its service-driven enterprise architecture. Specifically, these are some questions to ponder: Can service-oriented enterprise architecture meet the challenges from both mobile service demand and mobile device constraints? Can enterprises integrate their existing services and create new mobile services for the mobile world? New architectural approaches are emerging, such as the Enterprise Mobile Service Computing (EMSC) and Enterprise Mobile Service Architecture (EMSA) to provide solutions to the challenges in the mobile realm. This chapter starts out by discussing the issues of enterprise mobile computing. It then explores general concepts of EMSC, their standards, such as wireless network standards as well as mobile web standards; protocols, such as HTTP/HTTPS and languages such as HTML5; and architectural styles, such as SOAPbased Web Services and RESTful Web Services. The core of the chapter delineates EMSA as a service-driven architectural approach to building and integrating mobile systems. EMSA includes several architectural views as follows: Enterprise Mobile Services (EMS): Enterprise mobile services encompass existing enterprise services, Web applications, Cloud services, and specific mobile services. The characteristics of mobile services and 29

30 their design principles are discussed. Enterprise Mobile Service Consumers: The enterprise mobile service consumers include different mobile devices, such as iphone, ipad and Android-based devices. The interaction patterns between enterprise mobile service consumers and EMS are presented. Mobile client computing (how to consume EMS) is also discussed. Enterprise Mobile Service Process (EMSP): The EMSP is a set of composed and managed services executed in mobile platforms and environments, and consumed by mobile devices for completing a complex business process. Enterprise Mobile Service Data (EMSD): The mobile context is a set of dynamic data that is applied for enabling context-awareness in EMSA. Enterprise Mobile SOA Infrastructure (EMSI): The EMSI is part of Enterprise SOA (Service Oriented Architecture) Infrastructure, which is a glue to connect wireless network to enterprise services and services in the Cloud. Enterprise Mobile SOA Management (EMSM): Due to the multitude of mobile devices and mobile platforms, it is critical to have appropriate management practices in place for managing the enterprise mobile service architecture. In this chapter, The EMSM principles are described and discussed. Enterprise Mobile Service Architecture Quality Ontology (EMSQ): The quality ontology includes mobile security, mobile performance, mobile availability, mobile scalability and mobile reliability. These aspects will be discussed. Finally, the chapter presents a case study and discusses the challenges of EMSC and EMSA in both research and practice. The challenges include mobile enterprise integration and real-time service computing. Background Mobile computing is a distributed computing model that allows mobile devices and their applications to connect/interact with other mobile devices, mobile applications, and servers or services in a wireless communication environment. It is designed for people who travel or work outside the boundaries of their organizations or homes and enables them to communicate, play, and work, by using mobile devices anywhere and anytime. The mobile computing model extends the traditional computing model which requires one to use stationary computing devices that are connected to the internet or the enterprise network through wire. Mobile computing has two major characteristics that differentiate it from other forms of computing [REF-11]: Mobility: Implies both physical and logical computing entities that can move, in which the physical computing entities include mobile users and mobile devices that change their locations. The logical entities are instances of running mobile applications, sensors, and mobile agents with wireless connection. The user carrying a mobile device can initiate a real-time connection with other mobile devices and systems if they can connect to a wireless network. Broad Reach: Mobile users can theoretically be reached at any time. As long as users carry an open device with power, they can be reached instantly, provided they don t block messages or not accept calls for some duration of time. The above stated characteristics generate five value-added attributes of mobile computing as shown in Table 2: 30

31 Table 2 - Value-Added Attributes of Mobile Computing. Value-Added Attributes Ubiquity Instant connectivity Convenience Personalization Description Ubiquity refers to the state and capacity of being available at any location and at any given time. A mobile device such as a smartphone or PDA offers ubiquity. Mobile devices enable users to connect easily and quickly to the intranet, Internet, other mobile devices, services, and database anywhere and anytime. It is convenient for users to operate in the mobile environment. All they need is an Internet enabled mobile device such as a smartphone. Mobile device is owned by individual person with his/her personal choice and usage plan. Mobile devices can be customized for individual consumers. Localization of products and services Knowing the user's physical location at any moment is the key to offering relevant products and services. Users can easily search and find the products and services nearby (within the realm of security constraints). Table 2 - Value-Added Attributes of Mobile Computing. Enterprise mobile computing is a new kind of mobile computing model which is designed for enterprises extending their business, infrastructure, and services to the mobile space mobile users and wireless network. The characteristics of mobile computing and their value-added attributes in Table 2 make enterprise mobile computing an important business and IT strategy. Specifically, enterprise mobile computing is listed as number one and number two in 2012 top strategy technologies by Gartner s report [REF-12] in which the Media Tablets and Beyond is listed as number one and the Mobile-Centric Applications and Interfaces is listed as number two. The fast expanding technology of cellular communications, wireless LAN, and satellite services has been making it possible for mobile users to access enterprise information anywhere and anytime. Figure 2 illustrates the evolution of mobile computing [REF-13]. 31

32 Figure 2 - Evolution of Enterprise Mobile Computing. General Constraints of Mobile Computing Mobile computing has its constraints and concerns for enterprises. This section describes general constraints of modern mobile computing. Deepak et al., described several mobility constraints and issues of first generation mobile computing [REF-14]. A. K. Gupta characterized the constraints of modern mobile computing as three aspects based on performance impact [REF-15]. The three aspects are: Mobile device constraints Network constraints Mobility constraints Despite mobile devices getting more powerful since iphone released in 2007, and modern mobile connection speeds becoming comparable to fixed-line broadband, there are still constraints to be dealt with in the mobile space. Mobile Device Constraints The constraints mainly include hardware constraints, software constraints, and communications constraints: 32

33 Hardware constraints: The characteristics of mobile computing hardware are defined by the size and form factor, weight, microprocessors, primary storage, secondary storage, screen size and type, means of input, means of output, battery life, communications capabilities, expandability and durability of the device. Table 3 lists hardware data of today s typical smartphones - both iphone 4GS and Android smartphone: Device Name iphone 4G2 Nexus One Size (in) Weight 4.54x2.31x0.37 (in) 4.7 x 2.35 x 0.45 (in) 140 g 130 g Display Input 3.5 inches (89 mm) diagonal 1.5:1 aspect ratio widescreen LED backlit IPS TFT LCD 640 x960 resolution at 326 ppi 4 buttons switch microphones, touch-screen, acceleration, orientation 3.7 in (94 mm) AMOLED with resolution of WVGA (480x800 pixels) touch-screen Micro-USB; 3.5mm CPU 900 MHz dual-core ARM Cortex-A9 1GHz, Qualcomm QSD8250 Snapdragon GPU PowerVR SGX543MP2 chipset, Adreno 200 GPU Capacity Memory 512 MB Storage 16/32/64 GB Camera 8 MP back-side illuminated sensor HD video (1080p) at 24/30 frame/s IR filter Battery Rear: 5Mpx, autofocus, LED flash, Geo-tagging, video recording Front:No Table 3 - Hardware of iphone 4GS and Android Smartphone. 512 MB RAM, microsd slot (supported up to 32 GB) 3.7V, 5.3 Wh (1,430 mah) 1400 mah Internal Rechargeable Li-ion User replaceable From Table 3, one can see that the limited size and means of input/output are big constraints for designing mobile application interfaces and browsers. Mobile device s limited capacity also impacts running large applications and storing large amounts of data. Moreover their short battery life impacts system stability, service availability and performance. Compared with PCs, camera and sensors are advantages in most mobile devices. They enable enterprises to create new applications and services using mobile camera and sensor technology. Software constraints: Mobile devices utilize a broad variety of system and application software. The primary system software is mobile operating system (MOS). The MOS constraints greatly impact mobile application software design and capacity for consuming enterprise mobile services. Popular MOS examples are ios 5.x, Android OS 4.x, Windows 7.x, Palm OS 1.x. MOS impacts application design through application programming interface (API) for applications and services. MOS also impacts architecture and deployment of mobile applications and services. Communication constraints: Mobile device can communicate with other mobile devices through wireless networking and send short messages by SMS service. The ability of a mobile device to communicate with 33

34 wired information systems and services, such as enterprise applications and services, and Cloud-based services is significant for mobile computing. The communication capabilities of mobile devices directly impact mobile application design. Mobile Device Network Connectivity iphone 4GS (2011) 2G - GSM 850 / 900 / 1800 / 1900 and CDMA 800 / G - HSDP 850 / 900 / 1900 / 2100 and CDMA xEV-DO Wi-Fi (802.11) (2.4 GHz only Bluetooth 4.00) Combined GSM/CDMA antenna: quad-band GSM/GPRS/EDGE ( ,800 1,900 MHz) Dual-band CDMA/EV-DO Rev. A (800 1,900 MHz) GLONASS, GPS Nexus One (2010) GSM 850 / 900 / 1800 / 1900, 3G HSDPA 900 / 1700 / 2100 Wi-Fi a/b/g, Bluetooth v2.1 with A2DP, A-GPS Nokia 1100 (2003) GSM (2G) Table 4 - Network and Connectivity of Mobile Devices. From Table 4, one can see that iphone 4GS and Nexus One can communicate using several different wireless communication standards, unlike older smartphones such as Nokia Mobile Network Constraints Mobile network constraints are focused on the connection behavior between mobile devices and mobile network providers in a wireless environment. The type and availability of the communication medium significantly impacts the type of mobile computing application that can be created. Although wireless networking has greatly improved, such as from 2G to 3G [REF-3], 4G [REF-16] and Wi-Fi (WLAN IEEE ) [REF-3], the wireless networks (Cellular networks) have some limitations [REF-14], such as packet loss, high latency due to power restriction and available spectrum, and mobility constraints, specifically in boundary of different networks, weak signal coverage area or strong signal interference area. Advanced mobile broadband (high speed cellular networks), such as 3G and 4G, have different Max Downlink (MDL) for stationary clients and moving clients, for instance 4G MDLstationary client=1gbps, but MDLmoving client=100mbps. Mobility Constraints In general, mobility is a characteristic of mobile objects. In mobile computing, the mobility is a quality attribute of the mobile computing system that includes mobile computation and communication. Figure 3 shows the relationship between mobility and mobile computing. The mobile objects typically move in three spaces physical, network, and information spaces. The mobility in different spaces has different impacts to mobile computing. The mobility constraints can be defined as adaptability and fault-tolerance of mobile computing systems. 34

35 Figure 3 - Relationship of Mobility and Mobile Computing. Mobility constraints in physical space (MCPS): Mobile computing systems should adapt to the mobile behaviors of network disconnection and reconnection, and poor connection as mobile users and devices move in their physical locations (space). Mobility constraints in network space (MCNS): Mobile computing systems should adapt to the mobile behaviors of possible poor performance in a complex network topology space with multiple links and routers when mobile application and service connections are moving in the network space. Mobility constraints in information space (MCIS): Information space consists of the large amounts of data scattered in the information superhighway the Internet (and Cloud). Mobility in information space means mobile users and applications access the information space when moving in their physical space. Mobility of mobile software components will negatively impact a mobile service system s quality of service (QoS) [REF-17], in which QoS mainly includes availability, performance and scalability. The possible temporary disconnection during application code migration process when moving in the physical space, can cause certain components to be unavailable for a short time. The high volume mobile access in peak time, with poor wireless connection, can cause poor system performance. Mobile computing systems should adapt to the mobile behaviors of possible poor performance and scalability when high volume mobile users and mobile applications access the information superhighway the Internet (Cloud) or access enterprise mobile services in private data centers. 35

36 Challenges of Enterprise Mobile Computing The mobile computing constraints described in the last section are also the constraints of enterprise mobile computing. Additionally, there are also other challenges that are significant to the architecture of enterprise mobile systems as listed below. Mobile Connection Challenge Modern enterprise applications and services are built to communicate with networks and the Internet. Users access enterprise applications and services through an enterprise network infrastructure. The network connection is the bridge to enterprise applications and services. The mobile connection between mobile devices and enterprise applications and services often disconnect or are of poor connection quality due to mobility and device portability. The mobile connect behavior causes poor availability and performance of enterprise mobile systems. Therefore one can map the connection issues to reliability, availability, performance, and fault-tolerance challenges for designing enterprise mobile systems. Mobile Heterogeneous Network Challenge Unlike most of the stationary computers that stay connected to a single network, mobile devices run into more heterogeneous network connections. While they leave the range of one wireless network transceiver and are routed to another, they may need to change transmission speeds and protocols as well. In some other situations, for instance, where a mobile device in adjacent cells overlap or where it can be plugged in for concurrent wired access, it may have to access several networks simultaneously. Moreover, mobile devices may need to switch interfaces, for example, when switching from cellular coverage to Wi-Fi. The heterogeneous network connectivity makes mobile networking much more complex than traditional networking [REF-3] Mobile Performance and Scalability Challenge Because of limited bandwidth, high latency, and mobility of mobile computing, mobile performance and scalability is an important issue. Mobile Internet access is generally slower than direct cable connections, using technologies such as GPRS and EDGE, and more recently 3G as well as 4G networks. These networks are usually available within range of commercial cell phone towers. Higher speed wireless LANs are inexpensive but have limited range (see Table 5).The speed of mobile computing depends on wireless network speed. Table 6 shows max speeds of different wireless networks. The slower networks cause higher latency. A research of mobile Web performance showed that 60% of all mobile users expect websites to load as fast as in a regular browser. But, 75% of all users experience slow load times as their #1 issue. [REF-18] 36

37 Wireless Network Standard Description Theoretical Max Data Speed GSM Global System for Mobile communication 12.2 KB/sec GPRS Global Packet Radio Service 60 KB/sec EDGE Enhanced Date rate for GSM Evolution 59.2 KB/sec HSCSD High-Speed Circuit-Switch Data 57.6 KB/sec 3G W-CDMA UMTS Third Generation wireless network standard Wideband Code Division Multiple Access Universal Mobile Telecommunication System 14.4 MB/sec 3.6 MB/sec UMTS-TDD UMTS + Time Division Duplexing 16 MB/sec TD-CDMA Time Divide Code Division Multiple Access 16 MB/sec HSPA High-Speed Packet Access 14.4 MB/sec HSDPA HSUPA 4G High-Speed Downlink Packet Access High-Speed Downlink Packet Access Third Generation wireless network standard 14.4 MB/sec 5.76 MB/sec LTE Long Term Evolution 100 MB/sec LTE Advanced Long Term Evolution Advanced 1 GB/sec WiMax IEEE e 128 MB/sec Table 5: Wireless Network Speed Comparison [REF-19][REF-20][REF-21] 37

38 Wireless Technology Data Rate Access Range Bluetooth 1 Mbps 10 meters UWB 50 Mbps <10 meters IEEE a Up to 54 Mbps <50 meters IEEE b 11 Mbps 100 meters IEEE g Up to 54 Mbps 100 meters IEEE n Up to 600 Mbps IEEE ac Up to 1300 Mbps HiperLAN/2 Up to 54 Mbps 30 meters GSM (2G) 9.6 Mbps Cell sizes 10 to 20 KM 3G Cellular Up to 2 Mbps Cell sizes 5 to 10 KM WLL (LMDS) Up to 37 Mbps 2 to 4 KM FSO 100 Mbps to 2.5 Gbps 1 to 2 KM Satellites 64 Kbps thousands of miles Table 6: Comparison of Data Rate and Access Range [REF-3][REF-22] The above Tables 5 and 6 show maximum or average transfer capacities of single link between an access point and a terminal. However, they do not cover the overall performance of wireless access networks, which is out of scope of this chapter. The mobile network performance is no longer about ensuring that the network is up, it isn t even about ensuring that capacity is available and coverage is provided as expected. It has become a combination of all three of these elements (availability, capacity, and coverage) in order to provide the network quality of service that customers expect. As smartphone usage proliferates, the devices and applications themselves will also become part of the network performance equation. Mobile Security Challenge Mobile security issues include mobile device security, wireless infrastructure security, mobile information (data), and information systems (apps and services) security. G.H Forman and J. Zahorjan addressed mobile security risk since 1994 [REF-23]. Amjad discussed mobile and wireless communication security [REF-3]. Dwivedi, et al. described information security issues in mobile computing [REF-24]. Moreover, the stealing and destruction of mobile devices are raising a big mobile security, trust, and privacy issue; since personal identity, and sensitive data, such as bank account details can be stolen. Some enterprises are adopting BYOD (Bring Your Own Devices) strategy [REF-25] to improve employee productivity and flexibility. If employee s devices (iphone, ipad, etc) with business data and sensitive corporate information are stolen or destroyed, then enterprises will be at risk. To preserve mobile device s integrity (different devices connect to different service providers) and prevent the cellular network from malicious attacks, the manufacturers of mobile devices and mobile network operators control access to critical mobile components, such as the file system, Internet services, multimedia features, Bluetooth, GPS, and communications, through a rights management system, such as signed keys from a Certificate Authority. However, this is not enough to protect enterprise mobile service systems from malicious attacks through 38

39 mobile channels, because mobile networks are more broad, more dynamic and easier to access than their fixed network counterparts. Making enterprise mobile service systems secure is a definite challenge. Enterprise Mobile Service Architecture This section presents a new architectural style Enterprise Mobile Service Architecture (EMSA) as a solution to addressing the challenges of enterprise mobile computing by presenting principles, design guidelines and best practice recommendations. The EMSA is a hybrid architectural style composed of enterprise mobile computing (EMC), enterprise SOA (ESOA), as well as enterprise Cloud service architecture (ECSA) as defined and specified in [REF-26]. The Figure 4 shows the relationship of EMSA and other enterprise architectural styles. Figure 4 - Relationship between EMSA and other Architectural Styles. The EMSA consists of several architectural views as indicated below: Enterprise Mobile Service (EMS) Enterprise Mobile Service Consumer Enterprise Mobile Service Data (EMSD) Enterprise Mobile Service Infrastructure (EMSI) Enterprise Mobile Service Process (EMSP) Enterprise Mobile Service Management (EMSM) 39

40 Enterprise Mobile Service Quality Attributes (EMSQ) The relationship among the architectural views of EMSA is shown in Figure 5: Figure 5 - Relationships among Architectural Views of EMSA. Figure 5 is based on the framework proposed in Tang s PhD Thesis Modeling and Analyzing Service-Oriented Enterprise Architectural Styles [REF-27] The EMSA architectural views describe the hybrid enterprise architectural style which includes components and connectors that form an enterprise mobile service system. The figure also depicts the design constraints in terms of the mobile quality attributes and their relationship with the other architectural views. The EMSA style is an abstraction of a family of concrete enterprise architectures that can provide design 40

41 principles and guidelines for designing concrete enterprise mobile service architecture. By Taylor s definition of architectural style, An architectural style is a named collection of architectural design decisions that are applicable in a given development context, constrain architectural design decisions that are specific to a particular system within that context, and elicit beneficial qualities in each resulting system [REF-28]. The EMSA style defined in this chapter can be applied to any enterprise mobile service development context as a high level architectural pattern. The EMSA style will be used for evaluating FedEx enterprise mobile service architecture in the case study section. The rest of this section describes all the architectural views of EMSA and provides guidelines and best practices. Enterprise Mobile Service (EMS) The manufacturers of mobile devices often provide built-in services, such as native SMS service, service, mobile Web Services, and Cloud services. For example, iphone 4S provides online services App Stores, such as, itunes store, ibook store and icloud. EMS is defined as the service in Enterprise SOA Systems that can be accessed from mobile devices for enabling enterprise m-businesses (mobile businesses) [REF-29], such as m-commerce (m-b2c and m-b2b), m-crm, m-erp, Wireless Advertising [REF-30] etc. Figure 6 - Enterprise Mobile Services. Figure 6 indicates three kinds of services exposed to mobile devices: Existing enterprise services Mobile specific services Cloud services 41

42 These services can be categorized based on different architectural styles as shown in Table 7: Mobile Services Component-based services [REF-27] SOAP-based Web services [REF-27] RESTful Web Services [REF-27] Cloud Services [REF-27] Description The service is built based on component architectural style such as J2EE,.NET, etc. Communication is based on RPC (such as RMI) and XML over HTTP. The service is built based on WS-* architectural style (EWS-*) and uses SOAP as its communication protocol and conforms to Web Service standards. The service is built on REST-based Web-oriented architectural style REST [REF-31] and EWOA (Enterprise Web Oriented Architecture). HTTP/HTTPS are its communication protocols. Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) Table 7 - Mobile Services with Different Architectural Styles. Hirsch, et al. described the standards, design principles and applications of SOAP-based Web services in [REF-32] It is found that RESTful Web Services are more suitable in many areas of enterprise mobile service computing. Constraints of Mobile Computing Limited device capacity of hardware and software. Limited bandwidth and battery power. Multitude of devices and Rich content in small mobile devices. Performance and scalability issues. Advantage of RESTful Web services Architecture simplicity: Client-server model with unified service interfaces. SOAP-based Web services use XML-based messages that need higher bandwidth and consume more power. RESTful JSON-based messages needs less bandwidth and consumes less power for processing. SOAP-based Web services support XML data format only, RESTful Web services support multiple media types: HTML, plain text, XML, JSON, PDF, Atom and more. Cacheable boots performance. Stateless increases scalability. Table 8 - RESTful Services as a Solution to Challenges of Mobile Computing. Table 8 maps constraints in mobile computing to a solution with RESTful Web Services. It illustrates that RESTful Web service is a better alternative for architecture choice for many mobile computing systems. However it does not mean that SOAP-based Web service will go away. Because of its message-level security feature and well-defined message contract, it will still be suitable for many mobile enterprise applications. However, SOAP-based Web service needs to continue improving its performance and reducing bandwidth. A solution architecture with RESTful Web Service and mobile Cloud service is shown in Figure 7, in which the 42

43 Cloud can be a private Cloud or any public Cloud such as Amazon Cloud, Google Cloud or Microsoft Cloud [REF-2, 8, 9, 10]. Figure 7 - Solution Architecture with RESTful Mobile Service or Mobile Cloud Service. Adopting Cloud services for enterprise mobile service computing is a new trend which is called Mobile Cloud Computing [REF-11,12]. The Cloud can help enterprises to meet some of the challenges of mobile service computing. The IaaS can help enterprises to build highly dynamic, scalable, and highly available mobile infrastructure services. The PaaS can help enterprises to develop, deploy, and run mobile applications and services quickly and in a cost-effective manner. The SaaS can provide additional mobile service capacities. Enterprise Mobile Service Consumer Mobile devices are provisioned with applications that can access and consume services locally or remotely. Enterprise mobile service consumer can be defined as any mobile application or user interface that is provisioned in the mobile devices, and that can access and consume enterprise mobile services for enabling enterprise m-business. This chapter emphasizes on mobile Web applications [REF-13, 14], and interfacing of mobile devices to enterprise SOA systems with Web technology, such as Web Services, Ajax, Javascript (JQuery mobile), and HTML5 [REF-39]. 43

44 Figure 8 - Interaction Pattern of Mobile Service Consumers and SOAP-based Mobile Web Services. Figure 9 - Interaction Patterns of Mobile Service Consumers and RESTful Mobile Web Services. When stationary devices, such as a PC or wireless laptop accesses enterprise web services (SOAP-based or REST-based) through wired connection or WEB access point network, the request is directly routed to the Internet. However, with mobile devices, such as iphone or Blackberry, when accessing enterprise web services through the Internet, the request/response has to be routed through the wireless operator s cellular network and wireless operator s proxy servers. Therefore mobile devices exhibit greater latency when compared to stationary devices for sending message requests to or getting responses from the enterprises services. Figures 8 and 9 illustrate the typical Web service styles used for mobile computing. SOAP uses the same 44

45 URL for all interactions. The SOAP server parses the SOAP message to determine which method to invoke. All SOAP messages are sent with HTTP POST requests. However, REST uses different URLs to address resources. The Web server dispatches a request to a handler (URL addresses a handler) and REST maps the request to standard HTTP methods. RESTful mobile service interaction is simpler than SOAP-based Web services. Therefore mobile services lean towards using RESTful Web Services. Mobile applications are becoming an important consumer for enterprise services, however, they face many challenges with respect to device variations and constraints. HTML5 as the next generation hypertext language that brings new solutions to some of these issues. HTML5 enables mobile users to experience richer Web applications and improved usability. HTML5 compliant Mobile browsers reclaim the rendering of rich Web content from third-party plug-ins. Figure 10 - HTML5 New Technology and API. HTML5 shown in Figure 10, provides advanced features to build sophisticated mobile Web sites, and helps resolve challenging issues of EMSA as shown in Table 9: 45

46 Constraints & Issues of Mobile Computing Limited capacity of hardware and software. Limited bandwidth and battery power. Issues on mobility, such as lost connection, out of coverage areas. Issues with variable devices and rich content in small mobile devices. Issues in performance and scalability. HTML5 features Rich features for supporting modern mobile Web applications. HTML5 documents use a manifest to list all dependent external resources (i.e. CSS files, JavaScript libraries, etc.). Mobile browsers can use the manifest to cache an entire Web application for offline use, allowing mobile users to interact with a Web app while roaming in and out of coverage areas. The Web Storage API allows documents to persistently store data in a mobile browser. Mobile browsers can write data in one browsing session and read it in the next session. HTML5 processing speeds are improving, with the notable exception of CSS 3D transforms. Has AJAX support asynchronous communication. Has Websocket support this reduces HTML message overhead and provides duplex communication and lower latency. Supports real-time Web applications. Table 9 - HTML5 Features for Mobile Computing. Enterprise Mobile Service Data (EMSD) and Mobile Context Tang described general SOA data entity [REF-1, 2], that includes various service descriptions, and infrastructure configuration data. SOA Data Entity is also applicable to the Data part of EMSD. However, mobile computing is different from traditional distributed computing. In desktop computing, most parameters in the environment are relatively stable, and has constant context. Likewise, notebook/laptop computers are designed for stationary use so there is usually little variation in the situation surrounding their usage. In contrast, the environment of ultra-mobile computing is characterized by change. The mobile context is a dynamic data set. In IoT systems (Internet of Things) [REF-15, 16], mobile users will be able to dynamically discover and interact in an impromptu manner with heterogeneous computing environments and physical resources encountered during their roam [REF-36]. Mobile context can be used for enabling this kind of context-aware mobile service systems. Several authors [REF-17, 18] define mobile context concept and discuss its application. The mobile context can be defined as a set of dynamic data that is applied for enabling context-awareness in EMSA style systems. The context-awareness is defined as a service capacity with full awareness of current service execution environment that includes location, time, and user information. The Table 10 describes four types of mobile context [REF-38] in EMSA. The mobile context can be applied in mobile systems to provide context awareness for applications. Enterprise mobile service providers, such as Google and Facebook, make their services dynamically adaptable to the environment of mobile devices and mobile Web clients by using mobile context-awareness. 46

47 Physical context and time context are applied for monitoring mobile service systems, such as detecting error, traffic jam monitoring for providing vehicle routing information, etc. User context awareness provides automatic recommendation and situation-based adaptation of services and products. Mobile Context Description Examples Physical context Real physical environment which is accessible by using sensors and other resources deployed in the environment. User Location Traffic condition Time context Real time of any activity executing in the mobile system. Time: minutes, seconds, day, week, month and year Computing context Capacity and resources of mobile computing that can be detected by the mobile system. Device capacity Wireless type User context User information which the mobile system can be aware of. User profile People nearby Current social situation Table 10 - Mobile Context and Context Awareness. Enterprise Mobile Service Process (EMSP) Tang et al. specified and discussed the general enterprise service process (ESP) in ESOA style [REF-2, 10]. The ESP is a set of composed and managed services for completing a complex business process, such as online shopping or shipping workflow, or any business transaction process. The EMSP is an extension of ESP in enterprise mobile integration. The EMSP can be defined as a set of composed and managed services executed in mobile platforms and environments, and consumed by mobile devices for completing a complex business process. Traditionally, humans participate in an ESP, by logging in and providing information so that workflow execution can proceed, such as in insurance policy claim or inventory control. In the mobile realm, user interaction screen is delivered directly to the mobile user s device. Mobile service process can enable real-time, contact-aware and adaptive workflow. In this chapter, the design principles, architecture, and application of the following three types of enterprise mobile service processes are discussed: 1. Mobilizing existing ESP consumed by stationary computers, such as PCs and workstations. This type of EMSP includes m-b2c, m-b2b, m-b2g (mobile business to government), m-g2b [REF-29] which are extensions of B2C, B2B, B2G, and G2B. Figure 11 is a high level view of mobilized ESP. The basic steps for mobile-enabling existing ESP are: Adding mobile devices as consumers of existing ESP Adding mobile access point in enterprise service infrastructure Building mobile apps in devices for enabling to run end user work processes, such as JQuery mobile or HTML5-based mobile Web apps 47

48 Exposing existing enterprise service processes to mobile user s App space through a mobile-enabled interface gateway or broker, such as WSI which is based on SOAP Web service. Recently, RESTful Web services are being adopted for improving performance. Enterprise Web Oriented Architecture style process is extended to EMSP. Enabling an existing workflow engine in application servers of enterprise data centers to execute workflow within a mobile communication environment Providing EMSM for monitoring and managing life cycle of mobile workflow Addressing performance, availability, and security Figure 11 - High-Level View of Mobilizing Enterprise Business Processes. 2. Provisioning mobile-based EMSP processes for completing a business task in mobile computing environment, such as in mobile Web Mashups, mobile social service processes, and context-based and context aware workflow (Hackmann, Haitjema, Gill, & Roman, 2006). The basic steps for implementing mobilebased EMSP are: Providing a light workflow engine in the mobile device, such as Sliver [REF-39] which is a BPEL workflow process execution engine for mobile devices that can execute business processes Using visual representations of workflow Integrating activity execution with mobile core platform features, such as ios and objective-c or Android OS and java mobile platform 48

49 Standardizing mobile interfaces and definitions to existing activities Enabling service discovery mechanism and service connection for each activity Addressing issues relating to mobility, adaptability, performance, availability, and security There are two types of mobile specific service processes that take advantage of mobility mobile context, adaptability, real-time and sensor capacity. They are: Context-aware mobile service workflow Agent-based mobile service workflow One of benefits of context-awareness for mobile workflow is to increase the adaptability of mobile workflow, so that mobile workflow can be successfully and more effectively executed in a dynamic and mobile environment. The mobile service composition for context-aware cooperation [REF-37] is a good example. Figure 12 shows an initiator who is not capable of executing an ad-hoc process requiring several mobile and stationary services. The context-awareness helps the process to find other devices or services in its vicinity for remote access if local application is not available. The Cisco and GE location-aware mobile healthcare workflow solution is another good industry example [REF-40]. The solution is already benefiting from real-time data on the location and movement of mobile equipment and patients through the GE AgileTrac RFID network to make smart decisions to improve care delivery and hospital operations. Figure 12 - Context-Aware Cooperation for Mobile Process Composition. 3. Using mobile Cloud service processes consisting of a set of Web services in the public Cloud and a set of Web services in the private Cloud. Majority of services in the process and workflow engine are located in the enterprise data centers. However, for mobile Cloud service processes, the service process as well as the majority of services and service process engines as well as management systems is located in the Cloud data centers. The architecture principles used in this case are a combination of the principles used in both mobile and Cloud computing paradigms. 49

50 Enterprise Mobile Service Infrastructure (EMSI) The SOA infrastructure is the heart of ESOA [REF-26] and it supports the transformation of business in an enterprise or between enterprises into a set of managed services or repeatable business tasks, that can be accessed over a network when needed. The network can be a local network, the Internet, or a wireless network. The EMSI is an extension of SOA infrastructure defined in ESOA style. One of the challenges of enterprise mobile computing is that the EMSI depends on one or more wireless networks operated by mobile network providers, such as AT&T, Verizon, etc. Any of the requests from any mobile service consumer to an enterprise mobile service (EMS) must go through the operator s backbone. Therefore the backbone impacts reliability, performance, security, and availability of enterprise mobile services. Choosing the right backbone with solid service level agreements is a very important consideration for enterprise mobile service infrastructure. Figure 13 shows a typical enterprise mobile service infrastructure with two parts: Wired SOA infrastructure that is in the enterprise data center Wireless infrastructure that is outside of the enterprise There are three major types of wireless networks in EMSI including: Cellular wireless networks Wireless LAN network (Wi-Fi) Satellite Networks img Figure 13 - Enterprise Mobile Service Infrastructure. The core of EMSI includes the following components: Existing wired infrastructure Mobile applications and services Mobile operating systems Mobile devices Mobile endpoint security agents Mobile network which includes WLAN (Wi-Fi), 2G/3G/4G wireless networks, and/or satellite network Enterprise network security perimeter, such as firewall (Mobile security is discussed in a later section) Tunnel gateway such as MEAP services Authentication service and user directory such as SSO and LDAP service Application servers Data storage Content repository As the EMSI is an extension of the SOA infrastructure, the infrastructure ontology defined in [REF-27] shows that EMSI is a connector for all of the components that include the components in EMS, Enterprise Mobile 50

51 Service Consumer, and EMSP. The architectural constraints of EMSI are parts of EMSQ. Mobile service management and mobile service quality are important aspects that impact the delivery of enterprise mobile services. The next two sections deal with these aspects. Enterprise Mobile Service Management (EMSM) The EMSM is an extension of the SOA Management of ESOA style. As discussed earlier, mobile service computing is different from traditional service computing. Except for following general SOA management principles, the EMSM has its specific aspects and principles based on mobile constraints, specifically on mobility, real-time, and highly dynamic behaviors. For instance, mobile web content is different in many ways from Web-to-desktop content. The mobile world is fragmented, there are hundreds of mobile device models, with different form factors, operating systems, and browsers. On the PC-Web world this is not an issue since both user interfaces and delivery mechanisms has been standardized for years. However, in the mobile world, web content must be routed to the user through an operator network, and additional operator specific content may be added during the download. Also, different devices render content differently, so when the Web server detects a specific device type it may choose to send a variant of the generic content to the requesting device. Finally, different devices are capable of handling the various components of a download differently (for example, images, text, and third-party content), which can dramatically vary download time. The comparisons of Web content on a mobile device and on a desktop are shown in Table 11: Web Content on a Mobile Device The mobile device connects to the mobile operator network. Every mobile request goes through the operator's backbone. The wireless networks can be dynamically changed by mobility. Finally, the request is routed to the Internet for downloading content from web servers. Content server may send different content depending on device capability. Web Content on a PC PC connects to the ISP (Internet Service Provider) ISP routes through the Internet to download content from web servers. Content server sends same content for every request. Table 11 - Difference between Mobile Web Content and PC Web Content. Table 11 shows challenges in EMSM, specifically the following issues: Mobile Device Management (including BYOD management) [REF-41] Mobile Network Management Mobile Data and Context Management Mobile Service and Apps Management Mobile Performance and Security Management Mobility Management 51

52 Mobile Enterprise Applications Platform (MEAP) is a multi-channel gateway for enterprise mobile application management. A comparison of Mobile Point Solution and MEAP Solution is shown in Figure 14. Obviously, MEAP solution facilitates higher manageability that can provide more operational flexibility and cost control for enterprises (Sybase Whitepaper on Mobility Advantage). MEAP addresses the difficulties of developing mobile software by managing the diversity of devices, networks, and user groups at the time of deployment and throughout the mobile solution s lifecycle. Figure 14 - Comparison of Mobile Point Solution and MEAP Solution. Mobile application and service monitoring is one of the most important components of EMSM. Without a monitor in the EMSM, performance and security management is not possible. MEAP is a middleware that manages connectivity and security, and can integrate with mobile monitors. For small and middle size enterprises, Cloud-based mobile service and application management is one of solutions. The Compuware Gomez provides a SaaS Cloud mobile monitoring service that can monitor both mobile websites and native mobile application experiences across platforms such as ios and Android (Compuware Mobile Monitoring webpage). Enterprise Mobile Service Quality Attributes (EMSQ) Tang et al. proposed a SOA quality tradeoff ontology that has a set of architectural constraints for designing general enterprise SOA style systems. An ESOA system should meet certain SOA quality attributes to achieve required Service Level Agreement (SLA) and Quality-of-Service (QoS). [REF-42][REF-43][REF-44][REF-45] list the following major SOA quality attributes for general enterprise SOA information systems: Performance Reliability Scalability Reusability 52

53 Maintainability Security Cost Interoperability Availability Flexibility Manageability Agility Simplicity Consciousness Accountability [REF-44] shows that all quality attributes are not equal and there are constraints when trying to meet different attributes, such as the flexibility which may impact performance. The tradeoff of SOA quality attributes is one of the key design principles for designing enterprise SOA systems. The EMSQ is an extension of SOA quality attributes in EMSA. [REF-42][REF-43] describe major quality attributes specifically for mobile service computing and includes adding the following quality attributes to the above list: Adaptability Mobility Mobile Performance: An enterprise mobile service system may consist of different components (web services, web farm, application servers, data storage, and mobile devices) and connectors (wired network, wireless network, Cloud, and sensor network, even satellite network). The figure 15 shows a simple end-to-end mobile service system. In the sample case, the elapsed time for a mobile device to get data from the enterprise web service is about Tmobile = t1+t2+t3+t4+t5+t6 (seconds). On the other hand, for a stationary device PC, the elapse time will be TPC=t0+t4+t5+t6 (seconds). Since t3 t0, the performance of the end-to-end mobile service system greatly depends on the performance of the networks in EMSI, specifically on its wireless network performance. Tables 5 and 6 show that different mobile communication standards have different wireless network performance. For instance 4G is not only faster than 3G, but also provides more QoS for mobile systems [REF-46]. Moreover, Wi-Fi standard IEEE ac is much better than IEEE a, since the data rate (up to 1300 Mbps) of IEEE ac is much faster than that (54Mbps) of IEEE a. Different wireless service providers support different standards with different cost, therefore properly choosing mobile standards and their operators is the first consideration. From Tables 3 and 4, it can be seen that different mobile devices have different performance. Choosing wireless carrier and selecting supported mobile devices are tied to the cost attributes. Form architecture design point of view, mobile service system design with different approaches also greatly impacts application level mobile performance. For example, adopting RESTful Web service may have better performance than using SOAP-based Web service in mobile SOA system. However its security issues needs to be addressed in RESTful mobile Web service system design. We have also shown that mobility has negative impact on mobile performance in the section on Mobility Constraints. 53

54 Figure 15 - End-to- end Performance of Mobile Service System. Mobile Security: The mobile application and communication security has been addressed in the book Engineering Wireless-Based Software Systems [REF-47]. The InformationWeek reports on the State of mobile security [REF-48] shows that mobile security is a concern for enterprise mobile users. The mobile device is more vulnerable than a wired computer. Therefore, building end-to-end mobile security into a mobile service system is an important consideration in EMSA. Both wired as well as the wireless infrastructure of the enterprise needs to be secured. One should not only consider the traditional security mechanisms, such as authentication and authorization of users, multi-level security check point and access control, but also consider mobile device security, wireless network security, mobile application security, and mobile data as well as content security [REF-49][REF-50]. In general, Enterprise mobile security includes the following core functions: User authentication (including PIV card) Device, mobile app and enterprise services access control Stored data encryption and end-to-end encryption for sensitive data, such as credit card Application whitelist/blacklist Content filtering and malware protection Security event monitoring, logging, and response Data leak protection & removable storage control Enterprise mobile users include employees, registered customers, and other users. Enterprise mobile service system should consider defining different policies for access control to enterprise resources based on the different security levels required for each resource. Evidently, employees can be allowed to access more resources with higher security level than registered customers and other users. The registered customers can be allowed to access more resources and app features than other users. For public mobile Cloud services, the registered or subscribed customers can be divided into different subscriber classes, such as Gold, Silver, Copper, etc. depending on their SLA and payment. Gold customers pay more than Silver and Copper customers, and will be allowed to access more resources and features. Other mobile users may only be allowed to access limited resources and features. Mobile Adaptability: Mobile adaptability can be defined as the ability that a mobile service system or mobile application can adapt to the mobile environment where mobile devices are in different mobility spaces such 54

55 as physical space, network space, and information data space. The mobile adaptive behavior discussed earlier arises due to a certain mismatch between mobile service or supply, and service consumer demand for resources. The mismatch often happens in low-level system resources, such as bandwidth, memory, CPU or battery power [REF-50][REF-51]. There are many different approaches for achieving adaptability in different circumstances and scenario. Kakousisa et al., investigates software adaptation of mobile and ubiquitous computing in [REF-51]. The general mobile software system adaptation loop is shown in figure 16. Figure 16 - System Adaptation Loop in Mobile and ubiquitous Computing. The Table 12 shows different types of mobile adaptability and corresponding strategies, framework, and architecture. 55

56 Adaptability Description Strategies, Frameworks, Solution Architecture Client and server adaptability Server/Network adaptability Proxy adaptability Proxy and client adaptability Middleware adaptability Client adaptability Application-aware adaptation is to use a collaborative partnership between mobile systems (OS) which provides total transparency: apps are completely aware of mobility and each mobile application copes with mobility on its own. The mobile adaptability is in the server /network level for handling network adaptive behavior, such as available bandwidth changes, disconnection due to user move, or bad battery. The mobile adaptability is in the service proxy. The mobile adaptability is in both the proxy and client. The mobile adaptability is handled by mobile middleware that supports QoS-aware or policybased adaptability. The mobile adaptability is handled by dynamic user interfaces and ondemand-code. Table 12 - Types of Mobile Adaptability. The Odyssey is a solution architecture for application-aware adaptation by multiple applications using diverse data types [REF- 12]. However it does not address replication of objects and dynamic reconfiguration. [REF-13] proposed a mechanism to store information, and replicate or cache objects when network disconnection happens. [REF-14] proposed a TranSend system which is applicationtransparent and supports dynamic reconfiguration. MobiGATE [REF-15] is applicationtransparent and supports dynamic reconfiguration. It applies coordination theory for mobile service composition and configuration [REF-16] discussed several mobile middleware for mobile adaptability, such as reflective middleware, and policy-based middleware. [REF-17] proposed agent-based middleware. [REF-18]proposed a QoS-Aware mobile middleware. Using on-demand-code, such as Javascript and other technologies, like HTML5, CSS3 [REF-19] to create dynamic user interface for adapting to different types of mobile devices. Mobility: This section describes the impacts to other system quality attributes by mobility as well as its impacts to system design. Enterprise architecture for Mobility extends enterprise service and application computing capacity and communication channels from non-mobile paradigm to mobile paradigm, however, the mobility of 56

57 software components may negatively impact the QoS of mobile service system [REF-60], such as availability and performance due to the fact that system may be unavailable or may be slow during the migration process. To overcome mobility s negative aspects, mobile systems should be designed with support for certain adaptability as detailed in the last section and for fault-tolerance as described earlier. There are two types of mobility in mobile computing systems [REF-60]: Physical Mobility: is the ability that mobile users with their devices can access information systems unimpeded while they are moving across different physical locations Logical/Code Mobility: is the capacity that the modules or components in the mobile system can dynamically move across servers during system execution There are two kinds of logical mobility (LM) [REF-61][REF-62]. Stateful Mobility or Strong Mobility (SM): This is the ability of a system to allow migration of both code and the execution state of an executing unit to a different computing environment. Stateless Mobility or Week Mobility (WM): This is the capacity of a system to allow just code movement across different computing environments. The Table 13 shows a classification of logical mobility mechanism. 57

58 Logic Mobility / Mobility Mechanism Code and Execution State Management Stateful/Strong Mobility Migration Proactive Reactive Remote cloning Proactive Data Space Management Binding removal Network reference Re-binding By copy By move Stateless/Weak Mobility Reactive Code shipping Standalone code Synchronous Asynchronous Immediate Deferred Code fragment Synchronous Asynchronous Immediate Deferred Code fetching Standalone code Synchronous Asynchronous Immediate Deferred Code fragment Synchronous Asynchronous Immediate Deferred Table 13 - Classification of Logic Mobility Mechanism. 58

59 Compared with non-mobile client-server style system in which the server has know-how logic and resources needed for providing a given service, the distribution of such know-how logic (code) and resources varies across the components in mobile systems. There are three types of mobile code systems for supporting logical mobility [REF-61][REF-62]: remote evaluation, code-on-demand, and mobile agent as shown in Table 14. Adopting proper architectural style is important when designing mobile service systems. The design guideline for selecting appropriate style is shown in Table 15. Fuggetta, et al., evaluated several code mobility technologies and discussed applications as well as issues of code mobility in [REF-61]. The technology of Logic/Code mobility is a promising solution for the design and implementation of large-scale distributed mobile systems because it overcomes drawbacks of traditional client-server computing. As the execution units belong to different users, and computation environments are managed by different organizations; and communication may take place through an insecure infrastructure (Internet), the security is a concern to use logical/code mobility technology. [REF-50][REF-61][REF-63] provide security solutions to code mobility. Type of System Architecture Description High-Level Diagram Remote Evaluation (REV) Code-on-Demand (COD) Mobile Agent (MA) There are source hosts and destination hosts. A component in source host has know-how logic but not the resources needed for performing the service. The component is transferred from source host to destination host where it is executed using the available resources. The result of the execution is returned to the source host. The needed resources are available in a host A which does not have know-how logic. The subsystem in host A requests the component (s) providing the knowhow logic from remote host(s), such as host B. The logic will be executed in host A. A software component (MA) located on a given host A, which has knowhow logic, some of execution state and has access to some of the resources needed to provide a service. The MA with its state and local resources may migrate to destination host that may have remaining resources needed for providing the service. Figure 17 - Remote Evaluation. [REF-24] Figure 18 - Code-on-Demand. [REF-25] Figure 19 - Mobile Agent. [REF-26] Table 14 - Architecture of Mobile Systems with Logic Mobility Mechanism. 59

60 Design Style / System Client-Server Remote Evaluation Mobile Agent Non Mobile Appropriate Code represented as data. Code receipt and execution must be programmed explicitly. Code and state represented as data. Execution and state restore must be programmed explicitly. Mobile with Weak Mobility Degenerated code Unnecessary execution units are created Degenerated code. Unnecessary execution units are created. Unnecessary state migration. Appropriate State represented as data. State restoring must be programmed explicitly. Appropriate Mobile with Strong Mobility Unnecessary state migration. Unnecessary overhead for migration. Table 15 - Appropriate Architectural Styles for Different Systems. We covered the major quality attributes in enterprise mobile service architecture. [REF-42] proposes a framework for quality metrics in mobile-wireless information systems. The author builds quality metrics and maps each metric to issues of mobile-wireless computing, such as Narrow band, Connection stability, and Security and privacy. Moreover, the author also builds a mapping from mobile quality metrics to standard quality characteristics. Case Study: Enterprise Mobile Solution FedEx is a successful transportation/shipping company in the world. Its mobile solution (Fedex Mobile) is a noteworthy implementation in enterprise mobile service computing. FedEx mobile solution includes mobile web solution and mobile sensor based real-time services. The FedEx mobile web solution consists of: Mobile App Store which carry mobile applications for different mobile devices with different OS such as iphone/ipad, Android and Blackberry Core services, such as shipping, tracking, rating, scheduling, pickup, and find location A solid SOA infrastructure [REF-67] as a foundation of its enterprise mobile service architecture Secure communication and data access with its user management and remote control to protect its business and enterprise services FedEx CIO Rob Carter in his Dominant Design presentation [REF-68] in InformationWeek provides an in depth look at how FedEx is building its data centers which are based on SOA and private/hybrid Cloud enterprise infrastructure architecture. Its core components include virtualized servers, modern network, intelligent storage, and SOA software architecture. The enterprise infrastructure architecture is the foundation of FedEx mobile solution. Another FedEx mobile solution is to provide sensor-based real-time mobile services. The new product SenseAwareSM powered by FedEx [REF-69] shows that sensors and the Internet of things (IoT) will dominate its mobility strategy in the future. This device is dropped into a package and can relay back location, temperature, data and even radioactivity levels if needed. Internet of Things (IoT) is one of the emerging 60

61 technologies [REF-70][REF-71]. Enterprise mobility as well as mobile service computing is basic technology for IoT realization. The sensors connect many different disciplines, including customer service, data management, analytics, and business intelligence. Unlike traditional mobile devices, wireless sensors are standard measurement tools which can be part of a mobile device or a wireless sensor device, equipped with transmitters to convert signals from process control instruments into a radio transmission. The radio signal is interpreted by a receiver which then converts the wireless signal to a specific desired output, such as an analog current or data analysis via computer software. Wireless sensors are very useful in infrastructure-free environments, such as sensor networks, ad-hoc networks for monitoring physical or environmental conditions such as temperature, sound, pressure, etc., and to cooperatively pass their data through the network to a main location. FedEx SenseAware can be used for customers monitoring shipment in-transit condition in near real-time. If an enterprise has infrastructurefree environments or ad-hoc networks like FedEx, then enterprise wireless sensor service architecture is an important part of the enterprise mobile solution architecture. As we briefly described, FedEx enterprise mobile solution is built on its solid enterprise SOA mobile architecture which is an instance of EMSA architectural style described in this chapter. As we defined in EMSA, the architectural style consists of seven architectural views. Let us examine the FedEx mobile architecture and see how it maps to a concrete EMSA style architecture. FedEx mobile architecture consists of a set of mobile Web services (EMS) such as FedEx mobile ship, mobile tracking, mobile locator, etc., which support its core business and provide online and offline services to its employees, customers and public users. More information is available from the FedEx mobile portal. FedEx mobile architecture provides its mobile applications in Apple store (ios), Google store (Android OS), and BlackBerry world, for mobile service consumers (Enterprise Mobile Service Consumers). FedEx mobile architecture is built on its hybrid private enterprise SOA infrastructure and integrates its existing infrastructure to the enterprise wireless sensor network (EMSI) through its SenseAware mobile innovation product and Rackspace Cloud. FedEx mobile architecture supports mobile workflow (EMSP) and allows mobile users to complete shipping process by using mobile devices. FedEx mobile architecture is designed with its mobile enhanced SOA management system (EMSM) for managing and securing its data center infrastructure and providing quality of service (QoS) for its mobile users (EMQS). FedEx mobile architecture is designed and implemented for meeting quality requirements, such as security, performance, scalability, and availability [REF-72]. FedEx mobile architecture improves its QoS by adopting new technologies and standards, such as x86 virtualized Linux platform, high-speed WLAN, and 3G above Cellular network. Recently, FedEx adopted Bluetooth wireless technology for its data collection device, the FedEx PowerPad, which gives FedEx couriers wireless access to the FedEx network, thereby enhancing and accelerating the package information available to its customers. The figure 20 describes a high-level view of FedEx mobile service architecture based on public information [REF-72][REF-73][REF-69][REF-71]: 61

62 Figure 20 - FedEx Enterprise Mobile Service Architecture. Future Research Directions EMSA is a rapidly developing trend in enterprise IT. EMSA is still in its infancy and is expected to grow substantially through future research work and practices. However, some of the open issues and challenges, such as dynamic resource provisioning, higher availability, performance, and scalability, need further research and development. Future research trends in mobile computing are pointing in the following directions: Extending enterprise mobile service computing to enterprise mobile Cloud service computing (EMCSC) [REF-73][ REF-35] Extending EMSA style to enterprise mobile Cloud service architecture (EMCSA) which is a hybrid style of ECSA style [REF-44] and EMSA style. Enhancing EMSI capacity and scalability by using Cloud IaaS [REF-73] Utilizing Cloud computing principles, such as dynamic resource provisioning, to enterprise mobile service computing design [REF-74] Extending mobile service to SaaS for mobile users Utilizing Storage as a service for improving mobile storage challenge Developing real-time mobile web applications for supporting IoT [REF-70] Developing mechanism for mobile QoS-awareness and SLA-awareness [REF-75]. 62

63 Conclusion This chapter presented the opportunities, challenges, issues, and solutions of enterprise mobile service computing. A case on FedEx mobile solution illustrates practical enterprise mobile service architecture. The EMSC as a new paradigm of distributed computing and a new architectural style brings great opportunity to enterprise businesses. Mobile applications and services build a new channel between enterprise business and its customers. However, EMSC faces many challenges and issues as discussed earlier. The main challenges include: Mobile device hardware and software challenge Mobile connection challenge Mobile heterogeneous network challenge Mobile performance and scalability challenge Mobile security challenge To solve those challenging issues, the chapter proposes an architectural style EMSA as an architectural solution which provides design guidelines for enterprise mobile application and service system. The EMSA includes a set of design constraints, principles and high-level common structure components, connectors and infrastructure. The mobile system design constraints include: Hardware constraints Software constraints Communication constraints Wireless network constraints Mobility constraints Enterprise architecture quality constraints, such as performance, security In summary, the major guiding principles for architecture of enterprise mobile systems are: Work around mobile system design constraints Meet enterprise software architecture quality and system non-functional requirements Tradeoff quality attributes and achieve a balanced whole quality (EMSQ) Utilize mobile context in system design, such as designing for context-aware and location-aware Apply Logic/Code mobility appropriately Choose the right style of mobile services for maximum performance Integrate mobile applications with enterprise core services Build mobile App stores for supporting multiple mobile devices Build enterprise mobile service infrastructure (EMSI) as a foundation Build enterprise mobile service management (EMSM) to guarantee end-to-end QoS and SLA 63

64 Disclaimer This chapter appears in Service-Driven Approaches to Architecture and Enterprise Integration, edited by Raja Ramanathan and Kirtana Raja, Copyright 2013, IGI Global, Posted by permission of the publisher. References [REF-1] Tang, L. (2011). Modeling and Analyzing Enterprise Service-Oriented Architectural Styles. PhD Thesis, CS of University of Texas Dallas, Nov [REF-2] Tang, L., Bastani, F. B., Tsai, W.T., Dong, J., & Zhang, L.J. (2011). Modeling and Analyzing Enterprise Cloud Service Architecture. Tech. Rep. UTDCS-26-11, Dept. of Computer Science, Univ. of Texas at Dallas, Sept [REF-3] Amjad, U. (2004). Mobile Computing and Wireless Communications, NGE Solutions, Inc., July 2004 [REF-4] Choi, H., Dawson, T., & La Porta, T. (2010). Network Integration in 3G and 4G Wireless Networks, Proceedings of 19th International Conference on Computer Communications and Networks (ICCCN), pp. 1-8, 2-5 Aug [REF-5] Canalys. (2012). Smart phones overtake client PCs in Retrieved from newsroom/smart-phones-overtake-client-pcs-2011 [REF-6] IDC. (2012). Retrieved from [REF-7] Esposito, D. (2012). Architecting Mobile Solutions for the Enterprise, Microsoft Press, [REF-8] Firtman, M. (2010). Programming the Mobile Web, O Reilly, [REF-9] Portio Research. (2012). Latest Mobile State. Retrieved from Ramdous, S., & Kannan, G. (2002). Security of Mobile Code. Journal of Cryptology, 2(1),2002, pp [REF-10] Taptu. (2010). The state of the mobile touch web. Taptu Report, Jan Retrieved from robertoigarza.files.wordpress.com/2009/07/rep-the-state-of-the-mobile-touch-web-taptu-2010.pdf [REF-11] Turban, E., McLean, E., & Wetherbe, J. (2006). Information Technology for Management, 2006, 5th Edition, Wiley & Sons, Inc. W3C. (2012). HTML5 Editor s Draft 7, Sept Retrieved from html5/spec/ [REF-12] Gartner. (2012). Gartner Identifies the Top 10 Strategic Technologies for Gartner Report. Retrieved from [REF-13] Reed, B. (2010). A brief history of smartphones. Network World, June 15, Retrieved from [REF-14] Deepak, G., & Pradeep, B.S. (2012). Challenging Issues and Limitation of Mobile Computing, International Journal of Computer Technology & Applications, Vol. 3 (1), pp , [REF-15] Gupta, A.K. (2008). Challenges of Mobile Computing. Proceedings of 2nd National Conference on Challenges & Opportunities in Information Technology, pp , March 29, [REF-16] Choi, H., Dawson, T., & La Porta, T. (2010). Network Integration in 3G and 4G Wireless Networks, Proceedings of 19th International Conference on Computer Communications and Networks (ICCCN), pp. 1-8, 64

65 2-5 Aug [REF-17] Taylor, R.N., Medvidovic, N., & Dashofy, E.M. (2010). Software Architecture: Foundations, Theory, and Practices, Wiley, [REF-18] Tjepkema, J. (2011). Guidelines for a Successful Mobile Customer Experience. Mobile Convention Amsterdam, 19 April [REF-19] Flinn, J., & Satyanarayanan, M. (1999). Energy-aware adaptation for mobile applications. SOSP-17 Kiawah Island, SC, Dec [REF-20] IEEE Retrieved from [REF-21] LTE Forum. (2011). Retrieved from [REF-22] IEEE IEEE Standards. Retrieved from [REF-23] Forman, G.H., & Zahorjan, J. (1994). The Challenges of Mobile Computing, IEEE Computer, pp.38-47, April [REF-24] Dwivedi, H., Clark, C., & Thiel, D. (2010). Mobile Application Security, McGraw-Hill, [REF-25] Borg, A. (2011). Mobility Becomes Core IT. The Aberdeen Group. SAP Mobility Insights Webcast Series, Part I, March 29, Retrieved from mobile_latest_march_28.pdf [REF-26] Tang, L., Dong, J., Peng, T., & Tsai, W.T. (2010). Modeling Enterprise Service-Oriented Architectural Styles. Service Oriented Computing and Applications (SOCA), Springer-Verlag, Vol. 4, p , [REF-27] Tang, L. (2011). Modeling and Analyzing Enterprise Service-Oriented Architectural Styles. PhD Thesis, CS of University of Texas Dallas, Nov [REF-28] Taylor, R.N., Medvidovic, N., & Dashofy, E.M. (2010). Software Architecture: Foundations, Theory, and Practices, Wiley, [REF-29] Amjad, U. (2004). Mobile Computing and Wireless Communications, NGE Solutions, Inc., July 2004 [REF-30] Gao, J., & Ji, A. (2010). Building An Intelligent Mobile Advertising System. The International Journal of Mobile Computing and Multimedia Communications (IJMCMC), January, [REF-31] Alshahwan, F., Moessner, K., & Carrez, F. (2010). Evaluation of Distributed SOAP and REST Mobile Web Services. International Journal on Advances in Networks and Services, Vol. 3, No. 3 & 4, pp , [REF-32] Hirsch, F., Kemp, J., & Llkka, J. (2006). Mobile Web Services Architecture and Implementation. Wiley, [REF-33] Dinh, H.T., Lee, C., Niyato, D., & Wand, P. (2011). A Survey of Mobile Cloud Computing: Architecture, Applications, and Approaches. Wireless Communications and Mobile Computing, Wiley, 11 Oct [REF-34] Sahu, D., Sharma, S., Dubey, V., & Tripathi, A. (2012). Cloud Computing in Mobile Computing. International Journal of Scientific and Research Publications, Volume 2, Issue 8, August [REF-35] Firtman, M. (2010). Programming the Mobile Web, O Reilly, [REF-36] Kunze, C.P., Zaplata, S., Turjalei, M., & Lamersdorf, W. (2008). Enabling Context-based Cooperation: 65

66 A Generic Context Model and Management System. In 11th Int. Conf. on Business Information Systems (BIS 2008), pp , Springer, [REF-37] Kaltz, J.W., Ziegler, J., & Lohmann, S. (2005). Context-aware Web Engineering: Modeling and Applications. Revue d Intelligence Artificielle 19 (3): pp [REF-38] Bellavista, P., Corradi, A., Fanelli, M., & Foschini, L. (2012). A Survey of Context Data Distribution for Mobile Ubiquitous Systems. ACM Computing Surveys, Vol. 45 (1), March [REF-39] Hackmann, G., Haitjema, M., Gill, C., & Roman, G.C. (2006). Sliver: A BPEL Workflow Process Execution Engine for Mobile Devices. Proceedings of 4th International Conference on Service Oriented Computing (ICSOC 2006). [REF-40] Horwitz, B. (2011). Cisco, GE Combine Location-Aware Technology to Track Patients, Equipment. eweek, 02/22/2011. Retrieved from LocationAware-Technology-to-Track-Patients-Equipment / [REF-41] Borg, A. (2011). Mobility Becomes Core IT. The Aberdeen Group. SAP Mobility Insights Webcast Series, Part I, March 29, Retrieved from mobile_latest_march_28.pdf [REF-42] Gafni, R. (2008). Framework for Quality Metrics in Mobile-Wireless Information Systems, Interdisciplinary Journal of Information, Knowledge, and Management, Vol. 3, pp , [REF-43] Garofalakis, Stefani, Stefanis, & Xenos, 2007; [REF-44] Tang, L. (2011). Modeling and Analyzing Enterprise Service-Oriented Architectural Styles. PhD Thesis, CS of University of Texas Dallas, Nov [REF-45] Tang, L., Dong, J., & Zhao, Y. (2011). SLA-Aware Enterprise Service Computing. Book Chapter 2 in Book Performance and Dependability in Service Computing: Concepts, Techniques and Research Directions, Edited by V. Cardellini, E. Casalicchio, K. C. Branco, J. Estrella and F.J. Monaco. IGI Global Publishing, July [REF-46] Choi, H., Dawson, T., & La Porta, T. (2010). Network Integration in 3G and 4G Wireless Networks, Proceedings of 19th International Conference on Computer Communications and Networks (ICCCN), pp. 1-8, 2-5 Aug [REF-47] Gao, J., Shim, S., Mei, H., & Su, X. (2006). Engineering Wireless-Based Software Systems. Artech House Publisher, August [REF-48] InformationWeek. (2012). Report 2012 on State of Mobile Security, May Retrieved from [REF-49] html [REF-50] Díaz, L., & Ekman, U. (2011). Introduction to Mobile ubiquity in public and private spaces. Digital Creativity, 22:3, pp , [REF-51] Dwivedi, H., Clark, C., & Thiel, D. (2010). Mobile Application Security, McGraw-Hill, [REF-52] Kakousisa, K., Paspallisa, N., & Angelos, G. (2010). A survey of software adaptation in mobile and ubiquitous computing. Enterprise Information Systems, Vol. 4, Issue 4, [REF-53] Satyanaryanan, M., Noble, B., Kumar, P., & Price, M. (1995). Application-Aware Adaptation for Mobile 66

67 Computing. ACM SIGOPS Operating Systems Review, Volume 29 Issue 1, pp , Jan [REF-54] Baggio, A. (1998). System Support for Transparency and Network-aware Adaptation in Mobile Environments. Proceedings of ACM Symposium on Applied Computing, Feb. 27th March 1, [REF-55] Fox, A., et al. (1996). Adapting to Network and Client Variability via On-Demand Dynamic Distillation. Proceedings of 7th Internet Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOSVII), pp , [REF-56] Zheng, Y., Chan, A., & Ngai, G. (2010). Applying Coordination for Service Adaptation in Mobile Computing. IEEE Internet Computing, pp , [REF-57] Keeney, J., Cahill, V., & Haahr, M. (2007). Techniques for Dynamic Adaptation of Mobile Services, Handbook of Mobile Middleware. Edited by Paolo Bellavista, [REF-58] Bellavista, P., Corradi, A., & Stefanelli, C. (2001). Mobile agent middleware for mobile computing. IEEE Computer, pp , March [REF-59] Nahrstedt, K., Xu, D., Wichadakul, D., & Li, B. (2001). QoS-Aware Middleware for Ubiquitous and Heterogeneous Environments. IEEE Communications Magazine, pp. 2-10, November [REF-60] Esposito, D. (2012). Architecting Mobile Solutions for the Enterprise, Microsoft Press, [REF-61] Taylor, R.N., Medvidovic, N., & Dashofy, E.M. (2010). Software Architecture: Foundations, Theory, and Practices, Wiley, [REF-62] Fuggetta, A., Picco, G.P., & Vigna, G. (1998). Understanding Code Mobility. IEEE Trans. on Software Engineering, 24(5), [REF-63] Taylor, R.N., Medvidovic, N., & Dashofy, E.M. (2010). Software Architecture: Foundations, Theory, and Practices, Wiley, [REF-64] Portio Research. (2012). Latest Mobile State. Retrieved from Ramdous, S., & Kannan, G. (2002). Security of Mobile Code. Journal of Cryptology, 2(1),2002, pp.1-12.( [REF-65] (Referenced from [REF-66] (Referenced from [REF-67] (Referenced from [REF-68] Data Center Knowledge. (2011). Fedex opens Colorado Springs Data Center, Feb Retrieved from [REF-69] InformationWeek. (2011). InformationWeek Video, Sept Retrieved from informationweek.com/video/ [REF-70] Logica. (2012). The Internet of Things, Retrieved from [REF-71] Hwang, K., Fox, G.C., & Dongarra, J.J. (2012). Distributed and Cloud Computing: From Parallel Processing to the Internet of Things. Elsevier, [REF-72] Babcock, C. (2011). 6 Lessons Learned From FedEx Private Cloud. InformationWeek, Sept. 13,

68 [REF-73] Data Center Knowledge. (2011). Fedex opens Colorado Springs Data Center, Feb Retrieved from [REF-74] Dinh, H.T., Lee, C., Niyato, D., & Wand, P. (2011). A Survey of Mobile Cloud Computing: Architecture, Applications, and Approaches. Wireless Communications and Mobile Computing, Wiley, 11 Oct [REF-75] Hong, T.D., Chonho, L., Dusit, N., & Ping, W. (2011). A Survey of Mobile Cloud Computing: Architecture, Applications, and Approaches. Wireless Communications and Mobile Computing. Oct. 2011, Wiley. 68

69 Certified Cloud Architect January 6-10, 2014 Dallas, Texas Certified Cloud Architect January 13-17, 2014 Sao Paulo, Brazil Certified SOA Architect January 20-24, 2014 Utrecht, Netherlands Cloud Architect Certification January 6-8, 2014 Hong Kong, Hong Kong Cloud Architect Certification January 6-10, 2014 Dallas, TX, United States Cloud Architect Certification January 13-17, 2014 Singapore, Singapore Cloud Architect Certification January 13-17, 2014 São Paulo, Brazil SOA Architect Certification January 13-17, 2014 Bangalore, India SOA Architect Certification January 20-24, 2014 Utrecht, Netherlands SOA Analyst Certification February 10, 12, 17, 19-20, 2014 Bogotá, Colombia SOA Governance Specialist Certification February 10, 12, 17, 21-22, 25, 2014 Bogotá, Colombia SOA Java Developer Certification February 10-12, 18, 26-27, 2014 Bogotá, Colombia SOA Security Specialist (Partial) Certification February 12-14, 2014 London, UK Cloud Technology Professional Certification February 17-19, 2014 Petaling Jaya, Malaysia Q1/2014 Certified SOA Architect SOA Architect Certification January 20-24, 2014 Singapore, Singapore SOA Architect Certification February 17-21, 2014 Melbourne, Australia January 27-31, 2014 Cape Town, South Africa Certified Cloud Architect March 3-7, 2014 Berlin, Germany Certified SOA Architect March 3-7, 2014 Toronto, Canada Certified SOA Architect March 3-7, 2014 Mexico City, Mexico Certified SOA Consultant February 10-12, Bogota, Columbia Cloud Technology Professional February 17-21, 2014 Melbourne, Australia Certified Cloud Architect February 24-28, 2014 Toronto, ON, Canada Cloud Architect Certification January 20-24, 2014 Melbourne, Australia SOA Consultant Certification January 20-24, 2014 Hamburg, Germany Cloud Technology Professional Certification January 27-29, 2014 Seattle, WA, United States SOA Architect Certification January 27-31, 2014 Cape Town, South Africa Cloud Architect Certification January 27-31, 2014 Amsterdam, Netherlands Cloud Architect Certification February 3-7, 2014 Santa Clara, CA, U.S SOA Analyst Certification February 3-7, 2014 PST, Virtual Cloud Technology Professional Certification February 4-6, 2014 Guadalajara, Mexico Cloud Architect Certification February 9-13, 2014 Dubai, UAE SOA Security Specialist (Partial) Certification February 10-12, 2014 PST, Virtual Cloud Architect Certification February 10-14, 2014 Sydney, Australia SOA Consultant Certification February 10-14, 2014 Rotterdam, Netherlands Cloud Architect Certification February 10-14, 2014 London, UK SOA Architect Certification February 10-14, 2014 Bogotá, Colombia SOA Consultant Certification February 10-12, 17-18, 2014 Bogotá, Colombia SOA Architect Certification February 17-21, 2014 London, UK Cloud Architect Certification February 17-21, 2014 Brasília, Brazil SOA Architect Certification Febraury 17-21, 2014 Bangkok, Thailand Cloud Architect Certification February 24-28, 2014 Toronto, ON, Canada Cloud Architect Certification February 24-28, 2014 Naarden, Netherlands Cloud Architect (Partial) Certification March 3-5, 13, 2014 Mexico City, Mexico SOA Architect Certification March 3-7, 2014 Toronto, ON, Canada SOA Architect Certification March 3-7, 2013 Mexico City, Mexico SOA Architect Certification March 3-7, 2014 Frankfurt, Germany Cloud Architect Certification March 3-7, 2014 Berlin, Germany Cloud Architect Certification March 3-7, 2014 Austin, TX, United States SOA Consultant Certification March 3-5,10-11, 2014 Mexico City, Mexico SOA Java Developer Certification March 3-5,11-14, 2014 Mexico City, Mexico SOA Governance Specialist Certification March 3, 5,10, 17-19, 2014 Mexico City, Mexico SOA Governance Specialist (Partial) Certification March 10-12, 2014 Workshop Calendar

70 Certified Cloud Architect March 17-21, 2014 Rio de Janeiro, Brazil Certified Cloud Architect March 17-21, 2014 Athens, Greece Certified SOA Architect March 23-27, 2014 Riyadh, Saudi Arabia Certified SOA Architect March 30- April 3, 2014 Dubai, UAE Certified Cloud Architect May 19-23, 2014 Naarden, Netherlands Certified SOA Architect May 18-22, 2014 Riyadh, Saudi Arabia Certified SOA Architect Cloud Technology Professional Certified Cloud Architect Cloud Technology Professional June 2-4, 2014 Lagos, Nigeria April 7-17, 2014 London, UK April 14-16, 2014 Sydney, Australia April 28-29, 2014 Selangor, Malaysia Cloud Professional Certification March 10-13, 2014 Athens, Greece SOA Architect Certification March 10-14, 2014 Auckland, New Zealand Cloud Architect Certification March 10-14, 17-21, 2014 Athens, Greece SOA Architect Certification March 11-15, 2014 Panama City, Panama Cloud Architect Certification March 16-20, 2014 Riyadh, Saudi Arabia Cloud Professional Certification March 17-18, 2014 Athens, Greece Cloud Architect Certification March17-21, 2014 Rio de Janeiro, Brazil Cloud Architect Certification March 17-21, 2014 Auckland, New Zealand Cloud Architect Certification March 17-21, 2014 Athens, Greece Cloud Technology Professional Certification March 19-21, 2014 Naarden, Netherlands Cloud Technology Professional Certification March 19-21, 2014 Lagos, Nigeria SOA Architect Certification March 23-27, 2014 Riyadh, Saudi Arabia Cloud Architect Certification March 24-28, 2014 Sydney, Australia SOA Consultant Certification March 24-28, 2014 Munich, Germany Cloud Architect Certification March 24-28, 2014 Lagos, Nigeria SOA Architect Certification March 30 - April 3, 2014 Dubai, UAE SOA Consultant Certification March 31 - April 4, 2014 PST Cloud Architect Certification March 31 - April 4, 2014 Dallas, TX, United States SOA Architect Certification March 31 - April 4, 2014 Bogotá, Colombia SOA Consultant Certification March 31 - April 2, 7-8, 2014 Bogotá, Colombia SOA Java Developer Certification March 31 - April 2, 8-11, 2014 Bogotá, Colombia SOA Governance Specialist Certification March 31, April 7, 9, 14-16, 2014 Bogotá, Colombia Cloud Technology Professional Certification April 1-3, 2014 Mexico City, Mexico Cloud Technology Professional Certification April 7-9, 2014 Guadalajara, Mexico SOA Architect Certification April 7-11, 2014 London, UK SOA Architect Certification April 7-11, 2014 Fairfax, VA, United States Cloud Architect (Partial) Certification April 10-12, 2014 Guadalajara, Mexico Cloud Technology Professional Certification April 14-16, 2014 Sydney, Australia Cloud Architect Certification April 14-18, 2014 London, UK Cloud Professional Certification April 28-29, 2014 Selangor, Malaysia Cloud Architect Certification April 28 - May 2, 2014 Las Vegas, NV, United States SOA Architect Certification May 5-9, 2014 Quito, Ecuador SOA Consultant Certification May 5-7, 12-13, 2014 Quito, Ecuador SOA Java Developer Certification May 5-7, 13-16, 2014 Quito, Ecuador SOA Governance Specialist Certification May 5, 7, 12, 19-21, 2014 Quito, Ecuador Cloud Architect (Partial) Certification May 6-8, 2014 Mexico City, Mexico SOA Architect Certification May 18-22, 2014 Riyadh, Saudi Arabia Cloud Architect Certification May 19-23, 2014 Naarden, Netherlands SOA Consultant Certification May 19-23, 2014 Bangkok, Thailand Cloud Technology Professional Certification June 2-4, 2014 Lagos, Nigeria Cloud Technology Professional Certification June 2-4, 2014 Guadalajara, Mexico Q2/2014 Workshop Calendar

71 Contributors Jing Dong Jing Dong received the BS degree in computer science from Peking University and the PhD degree in computer science from the University of Waterloo. He has been on the faculty of Computer Science department at the University of Texas at Dallas and consulting in software industry. His research interests include services computing, formal and automated methods for software engineering, software modeling and design, and visualization. He is a senior member of the IEEE and the ACM. Contributions Enterprise Mobile Services Architecture: Challenges and Approaches Part III Enterprise Mobile Services Architecture: Challenges and Approaches Part II Enterprise Mobile Services Architecture: Challenges and Approaches - Part I SLA-Aware Enterprise Service Computing - Part II SLA-Aware Enterprise Service Computing - Part I Jürgen Kress An eleven year Oracle veteran, Jürgen works at EMEA Alliances and Channels. As the founder of the Oracle WebLogic and SOA Partner Community and the global Partner Advisory Councils. With more than 4,000 members from all over the world the SOA and WebLogic Partner Communities are the most successful and active communities at Oracle. Jürgen hosts the communities with monthly newsletters, webcasts and conferences. He hosts his Fusion Middleware Partner Community Forums, where more than 200 partners get the latest product updates, roadmap insights and hands-on trainings. Supplemented by many web 2.0 tools like twitter, discussion forums, online communities, blogs and wikis. For the SOA & Cloud Symposium by Thomas Erl Jürgen was a member of the steering board. He is also a frequent speaker at conferences like the SOA & BPM Integration Days, Oracle Open World or the JAX. Contributions MDM and SOA: Be Warned! Event-Driven SOA SOA in Real Life: Mobile Solutions SOA and User-Interfaces Understanding Service Compensation Securing the SOA Landscape Enterprise Service Bus Canonizing a Language for Architecture: An SOA Service Category Matrix Industrial SOA SOA Blueprint: A Toolbox for Architects 71

72 Berthold Maier Berthold Maier works in the T-Systems International department of Telekom Germany as Enterprise Architect. He has more than 19 years experience as developer, coach and architect in the area of building complex mission critical applications and integrations scenarios. Within eleven years as Oracle employee he has held several leading positions including chief architect in the consulting organization. Hi is the founder of many frameworks and take over the responsible for reference architectures around BPM/SOA and Enterprise Architecture Management. Berthold is also well-known as a conference speaker, book author and magazine writer. Contributions MDM and SOA: Be Warned! Event-Driven SOA SOA in Real Life: Mobile Solutions SOA and User-Interfaces Understanding Service Compensation Securing the SOA Landscape Enterprise Service Bus Canonizing a Language for Architecture: An SOA Service Category Matrix Industrial SOA SOA Blueprint: A Toolbox for Architects Rolf Scheuch Rolf Scheuch is co-founder of OPITZ CONSULTING and as Chief Digtial Officer responsible for the strategic development concerning the service portfolio and the necessary technology knowhow. Beside this Rolf is still active as a management coach with focus on developing a business goal based IT-strategy and establishing an effective business and IT alignment. Furthermore Rolf is well-known speaker at numerous conferences and an author of articles and books with topics like Master Data Management, Process controlling and BPM. Contributions MDM and SOA: Be Warned! 72

73 Hajo Normann Hajo Normann works for Accenture in the role of SOA & BPM Community of Practice Lead in ASG. Hajo is responsible for the architecture and solution design of SOA/BPM projects, mostly acting as the interface between business and the IT sides. He enjoys tackling organizational and technical challenges and motivates solutions in customer workshops, conferences, and publications. Hajo leads together with Torsten Winterberg the DOAG SIG Middleware and is an Oracle ACE Director and an active member of a global network within Accenture, as well as in regular contact with SOA/BPM architects from around the world. Contributions MDM and SOA: Be Warned! Event-Driven SOA SOA in Real Life: Mobile Solutions SOA and User-Interfaces Understanding Service Compensation Securing the SOA Landscape Enterprise Service Bus Canonizing a Language for Architecture: An SOA Service Category Matrix Industrial SOA SOA Blueprint: A Toolbox for Architects Andrzej Parkitny Andrzej Parkitny is an Enterprise Integration Architect. Andrzej has fourteen years of software development and software architecture experience. He has designed and developed solutions in the health insurance, finance, engineering, retail, telecommunications, and healthcare industries. He holds an Honours Bachelor of Science in Software Engineering (Computer Science) from the University of Toronto. He has extensive experience in Service Oriented Architecture, Application Architecture, Solution Architecture, Software Development and Data Architecture. His expertise in SOA is supported by a SOACP certificate (Certified SOA Architect). Contributions Modernizing Data Access in the Enterprise An Approach for Assessing SOA Maturity in the Enterprise 73

74 Danilo Schmiedel Danilo Schmiedel is one of the leading BPM and SOA System Architects at OPITZ CONSULTING. He has been involved in large integration-, business processes automation and BPM / SOA development projects where he implemented solutions for various customers. His main field of interest is focused on the practical use of BPM and SOA on a large scale. Additionally he works as BPM and SOA project coach. Danilo is a frequent speaker in the German Java and Oracle communities and has written numerous articles about the above topics. Before joining OPITZ CONSULTING Danilo worked as Software Engineer in several international projects. The Leipzig University of Applied Science has awarded his outstanding reputation in Contributions MDM and SOA: Be Warned! Event-Driven SOA SOA in Real Life: Mobile Solutions SOA and User-Interfaces Understanding Service Compensation Securing the SOA Landscape Enterprise Service Bus Canonizing a Language for Architecture: An SOA Service Category Matrix Industrial SOA SOA Blueprint: A Toolbox for Architects Guido Schmutz Guido Schmutz works as Technology Manager for the IT services company Trivadis. He has over 25 years as a software developer, consultant, architect, trainer, and coach. In Trivadis he is responsible for SOA, BPM and application integration, and is head of the Trivadis Architecture Board. His interests lie in the architecture, design, and implementation of advanced software solutions. He specializes in Java EE, Spring, Oracle SOA Suite and Oracle Service Bus. He is a regular speaker at international conferences and is the author of articles and several books. Guido is an Oracle ACE Director for Fusion Middleware & SOA. Contributions MDM and SOA: Be Warned! Event-Driven SOA SOA in Real Life: Mobile Solutions SOA and User-Interfaces Understanding Service Compensation Securing the SOA Landscape Enterprise Service Bus Canonizing a Language for Architecture: An SOA Service Category Matrix Industrial SOA SOA Blueprint: A Toolbox for Architects 74

75 Mala Ramakrishnan Contributions Unlock Your IT with API Management Longji Tang Longji Tang serves as a Senior Technical Advisor at FedEx s Information Technology Division where he has acted as a tech lead and/or architect on several critical ecommerce projects. Currently, Longji is the lead project manager for FedEx.com s Data Center Modernization project. His research focuses on software architecture and design, service-oriented architecture, service-oriented cloud computing and application, and system modeling and formalism. Prior to his tenure with FedEx, Longji worked from as an Information System and Software Engineering Consultant at Caterpillar and IBM. He has published more than 20 research papers from numeric analysis to computer applications in Journal of Computational Mathematics, Acta Mathematica Scienia and other publications. After graduating from Hunan University with a Bachelor of Engineering degree in Electrical Engineering in 1980, he worked as an associate research fellow at the Hunan Computing Center from 1980 to He began graduate studies at Penn State University in 1992 and graduated in 1995 with a Master of Engineering degree in Computer Science & Engineering and a Master of Art degree in Applied Mathematics. Longji has undertaken his PhD studies in Software Engineering as a part-time student at the University of Texas at Dallas since June, He obtained his PhD degree in Contributions Enterprise Mobile Services Architecture: Challenges and Approaches Part III Enterprise Mobile Services Architecture: Challenges and Approaches Part II Enterprise Mobile Services Architecture: Challenges and Approaches Part I Modeling and Analyzing Enterprise Cloud Service Architecture - Part I Modeling and Analyzing Enterprise Cloud Service Architecture - Part II SLA-Aware Enterprise Service Computing - Part II SLA-Aware Enterprise Service Computing - Part I 75

76 Bernd Trops Bernd Trops is a Senior Principal Consultant at Talend Inc. In this role he is responsible for client project management and training. Bernd is responsible for all Talend projects within the Deutsche Post and the introductions of new versions and components. Before Talend, Bernd was a Systems Engineer working on various projects for GemStone, Brocade and WebGain and therefore has extensive experience in J2EE and SOA. From 2003 to 2007 Bernd Trops worked as a SOA Architect at Oracle. Contributions MDM and SOA: Be Warned! Event-Driven SOA SOA in Real Life: Mobile Solutions SOA and User-Interfaces Understanding Service Compensation Securing the SOA Landscape Enterprise Service Bus Canonizing a Language for Architecture: An SOA Service Category Matrix Industrial SOA SOA Blueprint: A Toolbox for Architects Wei-Tek Tsai Dr. Wei-Tek Tsai received his B.S. from Computer Science and Engineering from Massachusetts Institute of Technology at Cambridge in 1979, M.S. and Ph.D. in Computer Science from University of California at Berkeley in 1982 and He is now Professor of Computer Science and Engineering in the School of Computing, Informatics, and Decision Systems Engineering at Arizona State University. He has authored more than 300 papers in software engineering, service-oriented computing, and cloud computing. He travels widely and has held various professorships in Asia and Europe. Contributions Enterprise Mobile Services Architecture: Challenges and Approaches Part III Enterprise Mobile Services Architecture: Challenges and Approaches Part II Enterprise Mobile Services Architecture: Challenges and Approaches - Part I 76

77 Clemens Utschig-Utschig Clemens worked as Chief Architect for the Shared Service Centre, Global Business Services, Boehringer Ingelheim in architecture, master data, service management and innovation. At the moment he works with holistic enterprise architecture that provides the methodological platform for the new master data management. He previously worked as a Platform Architect at Oracle Inc. in the United States, where he helped to develop next product strategy as well as the SOA BPM Suite. Contributions MDM and SOA: Be Warned! Event-Driven SOA SOA in Real Life: Mobile Solutions SOA and User-Interfaces Understanding Service Compensation Securing the SOA Landscape Enterprise Service Bus Canonizing a Language for Architecture: An SOA Service Category Matrix Industrial SOA SOA Blueprint: A Toolbox for Architects Torsten Winterberg Torsten Winterberg works for Oracle Platinum Partner OPITZ CONSULTING. As a director of the competence center for integration and business process solutions he follows his passion to build the best delivery unit for customer solutions in the area of SOA and BPM. He has long-time experience as developer, coach and architect in the area of building complex mission critical Java EE applications. He is a known speaker in the German Java and Oracle communities and has written numerous articles on SOA/BPM related topics. Torsten is part of the Oracle ACE director team (ACE=Acknowledged Community Expert) and leads the DOAG middleware community. Contributions MDM and SOA: Be Warned! Event-Driven SOA SOA in Real Life: Mobile Solutions SOA and User-Interfaces Understanding Service Compensation Securing the SOA Landscape Enterprise Service Bus Canonizing a Language for Architecture: An SOA Service Category Matrix Industrial SOA SOA Blueprint: A Toolbox for Architects 77

78 Arcitura IT Certified Professionals (AITCP) Community Join the thousands of members of the growing international Arcitura community. Launched for the first time in mid-2011, Arcitura Education made official social media communities available via LinkedIn, Twitter, and Facebook. These new communities join the already existing memberships of LinkedIn, Twitter, and Facebook platforms for the Prentice Hall Service Technology Book Series from Thomas Erl.

79 The Service Technology Magazine is a monthly online publication provided by Arcitura Education Inc. and officially associated with the Prentice Hall Service Technology Book Series from Thomas Erl. The Service Technology Magazine is dedicated to publishing specialized articles, case studies, and papers by industry experts and professionals in the fields of service-oriented architecture (SOA), cloud computing, Big Data, semantic Web technologies, and other areas of services-based technology, innovation, and practice.