论文部分内容阅读
Abstract: Many organizations have now adopted Service Oriented Architecture (SOA) as an architectural style to help them with architecture, design and implementation of their core services and systems. Most of these organizations are challenged in integrating SOA style with their overall Enterprise Architecture work. This framework links an SOA style with the Enterprise Architecture (EA) methodologies to help organizations organize their SOA effort as a key part of their Enterprise Architecture. The case study demonstrates the implementation of architecture goal with organization vision in service oriented organizational structure using services that align Business with Technology. The framework is validated and has reserved the privileges of SOA and EA.
Key words: SOA (service oriented architecture), EA (enterprise architecture), service oriented enterprise (SOE), SOE strategic architecture, SOE domain architecture, SOE solution architecture, SOE lifecycle, service oriented enterprise architecture (SOEA) framework.
1. Introduction
In business, not like the old days, agility and quality of service become more important. More strategic infrastructure, technology roadmap to meet the business need is needed. Service-driven transformation of business and IT vision of an enterprise is supported. Simplified Information Technology (IT) infrastructure, scalability, enterprise-wide customer and product information, governance and compliance with related regulations should be always checked while accelerating demand centric service.
IT is not any more supporting business, but it is aligned with business and it is what is proposed as Service Oriented Enterprise (SOE). This has influenced the organizational structure, from function or hierarchical orientation to service oriented organizational structure. Likewise architectural vision is derived from Business and IT [1].
EA defines the structure required for an organization to achieve its objectives. The scope is organization perspectives of IT & Business requirements. All the policies, principles, strategies and so on are fit in to the“big picture” of the enterprise. SOE assumes that all applications (IT) aligned with the business driven requirements of the enterprise. Therefore, Business, Application, Infrastructure and Information models are inseparable at a lower level (service). The “AS-IS” and“TO-BE” states can be defined at all level flexibly. Functional requirements, non-functional requirements and business objectives are all defined in service requirements [2].
This case study is targeted to show the validity of the framework and contribution of the research for the targeted beneficiaries including the academia and the software industry. The case study has considered about a dozen projects or applications to manifest the solution approach.
Particularly, the problems in the case study are thoroughly defined and tackled. To cite some of the problems, throughout the company there is no pattern observed to reuse the existing traditional solution approach and lesson learnt from the problems. On top of this the top management concerns are not properly attempted including the ability to introduce a new product line or marketing new services. Similar problems encountered with one system kept the rest of the applications disengaged from the entire system architecture or structure than sharing resources or infrastructure [3]. This has kept especially the high level decision support system users in frustration.
The applications running are fragmented while the company has corporate policy of unifying business process, service performance, access control categorized based on classification of user groups like applicants, instructors, students, ex-students alumni, customers, different levels of management and so forth.
The need for enterprise wide IT enabled system to reverse business inefficiency, inconsistency and ineffectiveness by better service delivery and performance is clearly visible. This is the enterprise goal with the strategy to have a conceptual architecture where systems are sharing a common architecture that can understand the services, uses lesson learnt from the patterns, advantages of architectural styles and reuse resources [4].
The impact of the case study is summarized under the findings section. The paper starts describing the cases study roadmap followed by the vision, goal, strategy and the scope of the architecture work.
The primary objective of this work is to elevate SOEA as a discipline and a guiding framework to benefit from using SOA and EA jointly in an enterprise. No doubt that given the researcher keynote sessions in conferences, seminars and lectures the anticipated objective is achieved.
The paper is organized as follows: Section 2 introduces the SOEA Framework. Section 3 describes the SOEA Roadmap. Section 4 elaborate SOE Strategic Architecture. Section 5 describe Rationale of the case study, Section 6 describe the problem definition. Section 7 shows As-Is Architecture, Section 8 shows the To-be Architecture. Section 9 identifies the lesson learnt and findings. Section 10 gives the conclusion.
2. The SOEA Framework
The framework designed after critically identifying the limitations of SOA and EA, overlapping, leverage best practices, address the challenges while executing SOA and EA concurrently or isolate, problems identified, and features anticipated to this endeavor. This research work has gone through critical literature review, experts and peers comment, inputs gathered from world class international conferences like Global Information Technology Management Association(GITMA), The SOA Open Group and other focus group discussions.
It is a three stage architecture development process starting from SOE Strategic Architecture is the Enterprise BITS layer at the top of the framework, SOE Solution Architecture is the Execution layer that consists of SOE Domain Architecture at the middle upper sub layer and SOE Solution Lifecycle at the lower end sub layer. The last stage is the SOE Delivery layer using service structure or architecture bounded by SOE End-to-end guideline. The highlight on each of the four major components of the framework depicted in Fig. 1 is described for close follow-up and understanding of the framework.
2.1 Enterprise BITS Layer
It’s the top section in Service Oriented Enterprise Architecture Framework (SOEAF) therein enterprise business, enterprise technology and enterprise quality of service (QoS) delivery architectural vision is defined and respective drivers are identified. BITS shows alignment of Business and IT bounded within a Service.
2.2 Execution Layer
This layer consists of Service Oriented Enterprise Domain Architecture (SOEDA) and SOE Solution Lifecycle. SOEDA is the higher level hierarchy within the execution layer which has two weakly related sub layers. This layer has system and data architecture at the enterprise level and application and information architecture at service level. All the architecture viewpoints are integrated by the technology/infrastructure architecture which is management centric process with various perspectives. Governance and security policy of corporate, service and technology usage, design and implementation are also defined here. The conceptual/logical and physical architectural design is inherited in the process.
The lower section of the layer is the SOE Lifecycle layer which is an iterative process. Iteration and vision are the two vital elements in the process of a successful software development available in the layer. The enterprise wide vision is attained at the top layer whereas this layer performs iteratively discovering and providing services and assures its compliance with the vision. This is a three stages process starting from business initiative, evaluation and commit resource to deliver quality of service.
2.3 Service Delivery Layer
It is the last layer in the structure where it implements the concept of availability window and end-to-end SOA ones the service request passes through the above three stages. Service is not merely about provider, consumer and registry rather it has to be seen from a bigger picture that it encompasses Service Description, Interface, Agreement (contract, user acceptance), Deployment (Implementation, Use and Maintenance). In addition a service in any form should be abided by the enterprise wide policy (e.g. governance and security).
2.4 End-to-End Guideline
This is a binding principle set to execute the SOEA Framework. Return on investment (ROI), cost effectiveness, efficiency and satisfaction on the result is guaranteed as long as the guideline is methodically followed. This section shares or allows you to define vision, strategy and context for every stakeholder or viewpoints from technical and Business perspectives.
This section of the framework guides the users to establish the required combination of team members based on perspectives for example business & infrastructure architectures team, Service level design, implementation and deployment and so forth. The guideline also demonstrates all required Artifacts/deliverables for every points of view or stakeholders.
The model or graphical representation of the framework process is shown in section 4 whereas the SOE end-to-end guideline is left for the sake of brevity of the paper. This is higher level abstraction of which is enterprise-wide service centric architectural framework. Enterprise is organized in corporate, division or department wise but values its existence by providing quality service. SOEA is an iteration process to develop the target solution architecture.
3. Roadmap
This section constitutes the overall enterprise architecture vision, goal and strategy within the scope of the research need. The deliverable of the case study is service architecture for the business domains of the enterprise. This can be generated from the Execution Layer of the SOEA Framework that is inspired by the vision and scope of the Enterprise BITS described below and in subsequent sections.
The roadmap as depicted in Fig. 2 shows service driven process as to which major steps an enterprise or organization shall take for efficient utilization of the legacy system and the organizational structure in place.
Fig. 1 SOEA framework.
Fig. 2 SOEA roadmap.
Fig. 3 SOEA process.
4. SOE Strategic Architecture
Enterprise is organized in corporate, division or department wise but values its existence by providing quality services. The holistic view of enterprise includes people, business, IT and process. Therefore, enterprises dare to provide services that support to accomplishment their Business, Technology and QoS delivery vision and goals as depicted in Fig. 3—SOEA Process. To start with although the problem definition section discusses the environment and context here it is essential to focus on the direction of the work.
4.1 Vision
To have leading service driven enterprise business domain architecture based on Service Oriented Enterprise Architecture (SOEA) Framework. As the result, the company will be able to achieve its enterprise business vision—to become Center of Excellence in ICT Education, Research and Development.
4.2 Goals
The architecture is expected to cover software requirements, predictive stakeholder view, acquire knowledge and objectives such as security, reuse and portability.
4.3 Strategies
The system should be structured in such a way that services can work together or may be reused with similar requirements. Thus, it requires service architecture on the bases of SOEA framework. Moreover, design service with perception to reduce operating costs, ROI (from IT) and increase customer satisfaction.
4.4 Governance
Both business and technology are controlled centrally in the existing organizational structure. There are policies to be taken care of in the procedures, regulations and business processes in defining service granularity.
Guiding company manuals, prospectus, brochures and contract agreements for several activities are available for the stakeholders to follow-up and act on in any decision. This guides the roles, responsibilities and accountability of every service provider and consumer whether it is Business or IT driven.
4.5 Scope
The scope of the case study is to provide a service architecture that encompasses the overall enterprise business domain architecture. This is an outcome of the application architecture, system architecture, business architecture and data/information architecture viewpoints. These viewpoints are of the “As-Is”analysis and technical specification of the system. For each perspective different systems are considered to demonstrate the concepts.
The system comprises of Decision Support System for Executives, Operational Management Information System (MIS), Faculties/Instructors, Human resource, Admission, Library, Registrar, Finance, Students Record, Course Management, Intranet, Resource planning and scheduler applications.
5. Rationale
In order to maximize the acceptance of the research outcome the need for validating the SOEA Framework using a case study is to be expected. The case study selected should have a real-world context that can demonstrate the impact of SOEA rather than exercising by means of hypothesis business scenario [5]. Some of the good reasons for an enterprise to qualify as a case study candidate are that it should run different applications in parallel, multi-stakeholders involvement, existing organizational structure that manifests its vision, layers of managerial and decision levels, organizational governance and policy, and range of services provided for customers.
The company is chosen for the case study as it satisfies the merits mentioned above, provides required facilities of the research specific and general objectives. Moreover, the enterprise was established with a vision“to become a centre of excellence in the area of Information and Communication Technology (ICT) Education, Research & Development”. This has also contributed to this endeavor substantially.
Since its inception in1997, it has been providing consultancy in IT policy & strategic planning, System Development, Applied Research, hands on experience in small, medium and large scale software development, customization, deployment and maintenance. Currently, organized to give security centered cutting edge consultancy services on financial solutions to banks and insurance including evaluation and preparation of Request for Proposal (RFP), test case scenarios and so forth.
On the other hand, it offers tertiary level graduate and under graduate academic programmes, tailored course design and delivery. Therefore, it is well placed to popularize the outcome and findings of the research for further enhancement.
This can be made by the faculties and students of Masters of Science (M.Sc.) programmes in Software Engineering and Computer Science courseware and research works in addition to the practitioners of the company who are exposed to the industry practice.
6. Problem Definition
As indicated earlier, the company was established as a specialized private ICT tertiary level education provider under its college on one side. The Computer Systems Engineering wing of the company, on the other side, is providing Business and IT consultancy that ranges from E-Governance to small scale system development.
The enterprise has three layers that are responsible to make decision at different levels. The top most management is the Executive Level Management(ELM), Middle Level Management (MLM) and Operational Level Management (OLM). Policy & Strategy matters, Business development & Control and follow-up & standards on the quality of services are taken care of by ELM, MLM and OLM respectively.
All the three levels require Decision Support System to expedite their tasks within budget, in time and other constraints. Therefore, each category of the enterprise structure has technical and business support for services they require either from fully or partially automated systems or otherwise. Service is expected from within the company that could be even internal payables and outside of the company that is definitely out of pocket payables.
For providing the various services, different technological infrastructure has been in place. And in each of the divisions different information systems are operational as identified in the scope of work. These applications share some common business functions, business processes and policies such as data access controls. The data access layer manages the communication between data entry front-end and the database using the security component. This would have been a data access object or a service as a pattern throughout the enterprise. In addition persistence operations and searching methods are implemented for every application independently [5].
The Data Manipulation or Control Languages can be shared and designed for every service. This is an instance of Software as a Service, missing in the existing applications, that permits and could be enabled depending on the privilege of users group. In the same way Application and Infrastructure as a Service is missing that could be again exploited within the enterprise. This is further explained using the efficiency and other metrics [4, 6-7].
The enterprise also receives requests on variety of services from various customers. All types of demands are coming from inter-enterprise and intra-enterprise. Inter-enterprise requests occur from management at all levels, instructors, active students, office announcements, career center, resource planning and scheduler, supervisors and clients. While intra-enterprise requests come from ex-clients, ex-students, external users like universities, employers, families, standard agencies, and others requesting for recommendations and certifications.
The enterprise has solved the system development problem using structure and object oriented methodologies which have introduced fragmented islands of applications, duplicated subsystems and in some cases inconsistency of data and information that tackles problem with tactic than by strategic plan. This approach has resulted in major problems of IT and Business challenges. It has incurred expensive infrastructure and require Service Integration & Standard, implementation of corporate wide governance of security and flexibility for new business processes accommodation.
Therefore, the systems solution should have adapted to the environment and meet the architecture and design constraints of open architecture for plug & play, scalability, common reuse of service, infrastructure and software knowledge. Although incremental development of systems is observed as there are subsystems and other software elements it lacks sharing the architectural vision and consideration for different points of view of the system.
In this validation process, the development of a system at enterprise-wide and software products for a particular application will be considered from different perspectives. The enterprise requires having the holistic picture from the points of view of the users, developers, interaction with other systems, outsourcing, and infrastructure.
7. As-Is Architecture
The structure required for the company is in place with the division of business functional or units roles and responsibilities in order to embark into its vision, mission and to achieve its objectives. The IT requirement of the corresponding business units is observed in the organizational structure as a support unit to the company. Hence, the data and information requirements of some of the business processes are not automated partly. One of the case in point is the capabilities of research findings and knowledge sharing, management and repository.
The applications running are after thought based on the business requirements or drivers. These high level business functionalities are what become software applications. Business function par say software application is comprises of different business processes and stakeholder [8].
The company has also experienced in some of its activities although not supported in the structure the potential of the IT driven service initiatives. This is illustrated in the facility of intranet mail exchange server to submit assignments, grades by the instructors, request for grade report and the like using the respective systems. All the policies, principles and strategies defined in the company (big picture) are compliant with the business and IT driven initiatives.
8. Enterprise-Wide System Architecture
The overall system architecture which is referred as the “Enterprise System Architecture” is represented by Fig. 4. This is captured to demonstrate the existing infrastructure configuration expressed in terms of hardware (servers, workstations, communication peripherals) and the corresponding software of the company.
Each system runs in its own accord as shown in the overview of the logical viewpoint representation of the key components within the enterprise software system and their interactions. This doesn’t promote reuse, data sharing and information interchange. Since most of the systems are stemmed from the functional structure of the enterprise, support for efficient execution of business faces a challenge.
For instance, if one stakeholder say a student wants to request information from the registrar, she/he needs to login first to the registrar system. In parallel, the same student will be forced to re-login to the library system for requesting another service from the library system.
The stakeholder qualifications are the same but requires independent authorization and authentication by each system than sharing it centrally or virtually. Therefore, central mechanism of enforcing standards and security policy across the enterprise is compromised at the expense of expensively installed infrastructure and potential prone to error or complex design [9].
Fig. 4 Enterprise system architecture.
9. Application Architecture
The enterprise runs a dozens of applications in parallel which are mean to give informative decisions matters at all levels. This is a typical situation in most of the organizations who have implemented IT solutions with non service oriented architectural style in place. Such type of architecture style or pattern is something technically reflects the holistic view of enterprise architecture.
This is the case with IT practitioners and business managers in most cases business and IT architectures owned independently. Likewise, infrastructure would have been organized easily having common platform, i.e., Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). Infrastructure architecture viewpoint is depicted in Figs. 5-6 to visualize the resource required and consumed by Student Record Management and Course Management applications as instances [8-10].
The applications are designed with the traditional software architecture approach that supports modular development of systems. Some of the applications are designed using a 3-tier or layered architecture, i.e., with distinct layers for presentation (User Interface), business logic and data access and others with n-tier i.e. web based interface [11].
Fig. 5 SIS infrastructure architecture.
Fig. 6 CMS infrastructure architecture.
10. To-Be Architecture
Service Oriented Enterprise assumes service as a working smaller unit application aligned with the business driven requirements of the enterprise. In service driven enterprise—Business, Application, Infrastructure and Information models are inseparable at a lower end. The “AS-IS” and “TO-BE” states are defined at all levels flexibly.
Software requirements (functional and non-functional) and business objectives are all defined in service requirements. It is unusual to assume IT as a support tool to business process to achieve enterprise-wide goals rather it is a strategic aligns for business competence. It is IT empowered business in a service. It exists autonomously and whose access is through standardized interface contract.
The service architecture applying SOAML (Service Oriented Architecture Modeling Language) for the business domain applications is depicted in Figs. 7-9 as instances. The service architecture modeling language is a standard modeling that encompasses customer and provider service views. Moreover, it serves for the cases of both Business driven and IT driven requirements [9].
10.1 Service Matrix
Vision of the enterprise is discussed in the beginning and reflected by the enterprise Business & IT services visions. The technology vision of each service is designed to have efficient, consistent user experience and business agility. The service business vision is to increase revenue, better ROI and good customer experience. Furthermore each service stakeholder and business processes are left from this paper to make it concise and to the point [12].
The service matrix summarized in Table 1 highlight to capture the percentage of duplication among the overall services throughout the dozen applications delivered to the same stakeholder from varies points of view.
There are 33 unique services (See Fig 10: S01 to S33) supplied for about 10 stakeholders in all the 12 applications running in the company. The analysis and impact of SOEA framework is covered in the following section.
Abbreviations used the application names in Table 1 are EMIS—Executive Level Management Information System; OMIS—Operational Level MIS; IMIS—Instructor MIS; CMS—Course Management System/Moodle; PMIS—Personnel MIS; AMIS—Admission MIS; RMIS—Registration MIS; and SIMS—Student Information Management System.
Fig. 7 Registration service architecture.
Fig. 8 Library service architecture.
Fig. 9 Course management service architecture.
11. Findings from SOEA
As mentioned above analysis based on SOEA design characteristics such as reuse, infrastructure efficiency, duplication and ROI can be derived from the table. However, some of the important lessons learnt and the findings will be highlighted as follows.
Although limited services are considered, compare to entire service exist and anticipated in the company, there are only 21% of the services uniquely serve particular stakeholders. This means that 79% of the services are shareable among stakeholders.
Here, a theoretical challenge among the lesson learnt is the solution architecture implementation should be open architecture and changeable with the concept of service refactoring [13]. The other lesson is the user interface should be easy to use for inexperienced users and enforce standard. There is a probability that a service load could go as high as 93% chances to be requested from any of the points of view. This means that the ability to handle high volume transactions with no performance degradation is one of the service goals that should be attained and worth consideration. This is partly solvable in design and partly in the appropriate infrastructure availability.
The minimum a service occurrence is 17% that requires supporting at least two users concurrently probably at a given time is predictable as seen from the study. This will again demand a meticulous corporate policy implementation and service delivery standard to assure security and data/information integration. It is as well expected to support both distributed and centralized processing capabilities. The last column in the table shows 58% of the applications reuse by sharing almost 100% from the rest of the applications from the enterprise services available.
Fig. 10 Service reuse.
Table 1 Service matrix review.
12. Conclusions
Many organizations have now adopted SOA as an architectural style to help them with architecture, design and implementation of their core services and systems. Most of these organizations are challenged in integrating SOA style with their overall Enterprise Architecture work.
This framework links an SOA style with the EA methodologies to help organizations organize their SOA effort as a key part of their Enterprise Architecture. The case study demonstrates the implementation of architecture goal with organization vision in service oriented organizational structure using services that align Business with IT. The framework is validated as shown in the conclusion Fig. 10 that it has kept the privileges of SOA and EA.
The Y-axis shows the (dozen) applications and the X-axis listed the overall services (S01 to S33) rendered by the corresponding applications. For example S28 can be rendered by one of the nine applications. Likewise when it is summarized: 65% of services are reused, 72% infrastructure efficiency and 51% Faster development time.
References
[1] A. Dico, Addressing enterprise business needs through SOA and TOGAF, in: Enterprise Architecture Practitioners Conference, Austin, 2007.
[2] J. Butler, D. Ellis, Enhancing the Enterprise Architecture with Service Orientation, CBDI Service Oriented Architecture Practice Portal, available online at: http://www.cbdiforum.com/secure/interact/2007-10/enh ancing_enterprise_architecture_service_orientation.php, 2007.
[3] J. Fronckowiak, SOA best practices & design patterns: key to successful service oriented architecture implementation, White Paper Published by Oracle Corp., 2009.
[4] D. Sprott, L. Wilkes, Enterprise Framework for SOA, available online at: http://www.cbdiforum.com/bronze/journal/2005-03/ent_f rame_soa1.php, 2005.
[5] D. Avison, J. Pries-Heje (Eds.), Research in Information Systems: A Handbook for Research Supervisors and Their Students, Elsevier Amsterdam, 2005, pp. 221-238.
[6] TOGAF Version 9 the Open Group Architecture Framework (TOGAF), Document Number: G091, ISBN: 978-90-8753-230-7, Published by the Open Group, 2009.
[7] M. Ibrahim, G. Long, SOA and EA Similarities and Differences.
[8] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 2nd ed., Addison Wesley, 2003.
[9] N. Bieberstein, S. Bose, M. Fiammante, K. Jones, R. Shah, Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap, IBM Press, 2005.
[10] I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2010.
[11] P. Kruchten, Architectural blueprints—the “4+1” view model of software architecture, IEEE Software 12 (6)(1995) 42-50.
[12] L.-J. Zhang, Services Computing: Foundational Discipline of the Modern Services Science, in: 31st Annual IEEE International Computer Software and Applications Conference (COMPSAC 2007).
[13] R. Knippel, Service Oriented EA, Censored Edition, Copenhagen, 2005.
Key words: SOA (service oriented architecture), EA (enterprise architecture), service oriented enterprise (SOE), SOE strategic architecture, SOE domain architecture, SOE solution architecture, SOE lifecycle, service oriented enterprise architecture (SOEA) framework.
1. Introduction
In business, not like the old days, agility and quality of service become more important. More strategic infrastructure, technology roadmap to meet the business need is needed. Service-driven transformation of business and IT vision of an enterprise is supported. Simplified Information Technology (IT) infrastructure, scalability, enterprise-wide customer and product information, governance and compliance with related regulations should be always checked while accelerating demand centric service.
IT is not any more supporting business, but it is aligned with business and it is what is proposed as Service Oriented Enterprise (SOE). This has influenced the organizational structure, from function or hierarchical orientation to service oriented organizational structure. Likewise architectural vision is derived from Business and IT [1].
EA defines the structure required for an organization to achieve its objectives. The scope is organization perspectives of IT & Business requirements. All the policies, principles, strategies and so on are fit in to the“big picture” of the enterprise. SOE assumes that all applications (IT) aligned with the business driven requirements of the enterprise. Therefore, Business, Application, Infrastructure and Information models are inseparable at a lower level (service). The “AS-IS” and“TO-BE” states can be defined at all level flexibly. Functional requirements, non-functional requirements and business objectives are all defined in service requirements [2].
This case study is targeted to show the validity of the framework and contribution of the research for the targeted beneficiaries including the academia and the software industry. The case study has considered about a dozen projects or applications to manifest the solution approach.
Particularly, the problems in the case study are thoroughly defined and tackled. To cite some of the problems, throughout the company there is no pattern observed to reuse the existing traditional solution approach and lesson learnt from the problems. On top of this the top management concerns are not properly attempted including the ability to introduce a new product line or marketing new services. Similar problems encountered with one system kept the rest of the applications disengaged from the entire system architecture or structure than sharing resources or infrastructure [3]. This has kept especially the high level decision support system users in frustration.
The applications running are fragmented while the company has corporate policy of unifying business process, service performance, access control categorized based on classification of user groups like applicants, instructors, students, ex-students alumni, customers, different levels of management and so forth.
The need for enterprise wide IT enabled system to reverse business inefficiency, inconsistency and ineffectiveness by better service delivery and performance is clearly visible. This is the enterprise goal with the strategy to have a conceptual architecture where systems are sharing a common architecture that can understand the services, uses lesson learnt from the patterns, advantages of architectural styles and reuse resources [4].
The impact of the case study is summarized under the findings section. The paper starts describing the cases study roadmap followed by the vision, goal, strategy and the scope of the architecture work.
The primary objective of this work is to elevate SOEA as a discipline and a guiding framework to benefit from using SOA and EA jointly in an enterprise. No doubt that given the researcher keynote sessions in conferences, seminars and lectures the anticipated objective is achieved.
The paper is organized as follows: Section 2 introduces the SOEA Framework. Section 3 describes the SOEA Roadmap. Section 4 elaborate SOE Strategic Architecture. Section 5 describe Rationale of the case study, Section 6 describe the problem definition. Section 7 shows As-Is Architecture, Section 8 shows the To-be Architecture. Section 9 identifies the lesson learnt and findings. Section 10 gives the conclusion.
2. The SOEA Framework
The framework designed after critically identifying the limitations of SOA and EA, overlapping, leverage best practices, address the challenges while executing SOA and EA concurrently or isolate, problems identified, and features anticipated to this endeavor. This research work has gone through critical literature review, experts and peers comment, inputs gathered from world class international conferences like Global Information Technology Management Association(GITMA), The SOA Open Group and other focus group discussions.
It is a three stage architecture development process starting from SOE Strategic Architecture is the Enterprise BITS layer at the top of the framework, SOE Solution Architecture is the Execution layer that consists of SOE Domain Architecture at the middle upper sub layer and SOE Solution Lifecycle at the lower end sub layer. The last stage is the SOE Delivery layer using service structure or architecture bounded by SOE End-to-end guideline. The highlight on each of the four major components of the framework depicted in Fig. 1 is described for close follow-up and understanding of the framework.
2.1 Enterprise BITS Layer
It’s the top section in Service Oriented Enterprise Architecture Framework (SOEAF) therein enterprise business, enterprise technology and enterprise quality of service (QoS) delivery architectural vision is defined and respective drivers are identified. BITS shows alignment of Business and IT bounded within a Service.
2.2 Execution Layer
This layer consists of Service Oriented Enterprise Domain Architecture (SOEDA) and SOE Solution Lifecycle. SOEDA is the higher level hierarchy within the execution layer which has two weakly related sub layers. This layer has system and data architecture at the enterprise level and application and information architecture at service level. All the architecture viewpoints are integrated by the technology/infrastructure architecture which is management centric process with various perspectives. Governance and security policy of corporate, service and technology usage, design and implementation are also defined here. The conceptual/logical and physical architectural design is inherited in the process.
The lower section of the layer is the SOE Lifecycle layer which is an iterative process. Iteration and vision are the two vital elements in the process of a successful software development available in the layer. The enterprise wide vision is attained at the top layer whereas this layer performs iteratively discovering and providing services and assures its compliance with the vision. This is a three stages process starting from business initiative, evaluation and commit resource to deliver quality of service.
2.3 Service Delivery Layer
It is the last layer in the structure where it implements the concept of availability window and end-to-end SOA ones the service request passes through the above three stages. Service is not merely about provider, consumer and registry rather it has to be seen from a bigger picture that it encompasses Service Description, Interface, Agreement (contract, user acceptance), Deployment (Implementation, Use and Maintenance). In addition a service in any form should be abided by the enterprise wide policy (e.g. governance and security).
2.4 End-to-End Guideline
This is a binding principle set to execute the SOEA Framework. Return on investment (ROI), cost effectiveness, efficiency and satisfaction on the result is guaranteed as long as the guideline is methodically followed. This section shares or allows you to define vision, strategy and context for every stakeholder or viewpoints from technical and Business perspectives.
This section of the framework guides the users to establish the required combination of team members based on perspectives for example business & infrastructure architectures team, Service level design, implementation and deployment and so forth. The guideline also demonstrates all required Artifacts/deliverables for every points of view or stakeholders.
The model or graphical representation of the framework process is shown in section 4 whereas the SOE end-to-end guideline is left for the sake of brevity of the paper. This is higher level abstraction of which is enterprise-wide service centric architectural framework. Enterprise is organized in corporate, division or department wise but values its existence by providing quality service. SOEA is an iteration process to develop the target solution architecture.
3. Roadmap
This section constitutes the overall enterprise architecture vision, goal and strategy within the scope of the research need. The deliverable of the case study is service architecture for the business domains of the enterprise. This can be generated from the Execution Layer of the SOEA Framework that is inspired by the vision and scope of the Enterprise BITS described below and in subsequent sections.
The roadmap as depicted in Fig. 2 shows service driven process as to which major steps an enterprise or organization shall take for efficient utilization of the legacy system and the organizational structure in place.
Fig. 1 SOEA framework.
Fig. 2 SOEA roadmap.
Fig. 3 SOEA process.
4. SOE Strategic Architecture
Enterprise is organized in corporate, division or department wise but values its existence by providing quality services. The holistic view of enterprise includes people, business, IT and process. Therefore, enterprises dare to provide services that support to accomplishment their Business, Technology and QoS delivery vision and goals as depicted in Fig. 3—SOEA Process. To start with although the problem definition section discusses the environment and context here it is essential to focus on the direction of the work.
4.1 Vision
To have leading service driven enterprise business domain architecture based on Service Oriented Enterprise Architecture (SOEA) Framework. As the result, the company will be able to achieve its enterprise business vision—to become Center of Excellence in ICT Education, Research and Development.
4.2 Goals
The architecture is expected to cover software requirements, predictive stakeholder view, acquire knowledge and objectives such as security, reuse and portability.
4.3 Strategies
The system should be structured in such a way that services can work together or may be reused with similar requirements. Thus, it requires service architecture on the bases of SOEA framework. Moreover, design service with perception to reduce operating costs, ROI (from IT) and increase customer satisfaction.
4.4 Governance
Both business and technology are controlled centrally in the existing organizational structure. There are policies to be taken care of in the procedures, regulations and business processes in defining service granularity.
Guiding company manuals, prospectus, brochures and contract agreements for several activities are available for the stakeholders to follow-up and act on in any decision. This guides the roles, responsibilities and accountability of every service provider and consumer whether it is Business or IT driven.
4.5 Scope
The scope of the case study is to provide a service architecture that encompasses the overall enterprise business domain architecture. This is an outcome of the application architecture, system architecture, business architecture and data/information architecture viewpoints. These viewpoints are of the “As-Is”analysis and technical specification of the system. For each perspective different systems are considered to demonstrate the concepts.
The system comprises of Decision Support System for Executives, Operational Management Information System (MIS), Faculties/Instructors, Human resource, Admission, Library, Registrar, Finance, Students Record, Course Management, Intranet, Resource planning and scheduler applications.
5. Rationale
In order to maximize the acceptance of the research outcome the need for validating the SOEA Framework using a case study is to be expected. The case study selected should have a real-world context that can demonstrate the impact of SOEA rather than exercising by means of hypothesis business scenario [5]. Some of the good reasons for an enterprise to qualify as a case study candidate are that it should run different applications in parallel, multi-stakeholders involvement, existing organizational structure that manifests its vision, layers of managerial and decision levels, organizational governance and policy, and range of services provided for customers.
The company is chosen for the case study as it satisfies the merits mentioned above, provides required facilities of the research specific and general objectives. Moreover, the enterprise was established with a vision“to become a centre of excellence in the area of Information and Communication Technology (ICT) Education, Research & Development”. This has also contributed to this endeavor substantially.
Since its inception in1997, it has been providing consultancy in IT policy & strategic planning, System Development, Applied Research, hands on experience in small, medium and large scale software development, customization, deployment and maintenance. Currently, organized to give security centered cutting edge consultancy services on financial solutions to banks and insurance including evaluation and preparation of Request for Proposal (RFP), test case scenarios and so forth.
On the other hand, it offers tertiary level graduate and under graduate academic programmes, tailored course design and delivery. Therefore, it is well placed to popularize the outcome and findings of the research for further enhancement.
This can be made by the faculties and students of Masters of Science (M.Sc.) programmes in Software Engineering and Computer Science courseware and research works in addition to the practitioners of the company who are exposed to the industry practice.
6. Problem Definition
As indicated earlier, the company was established as a specialized private ICT tertiary level education provider under its college on one side. The Computer Systems Engineering wing of the company, on the other side, is providing Business and IT consultancy that ranges from E-Governance to small scale system development.
The enterprise has three layers that are responsible to make decision at different levels. The top most management is the Executive Level Management(ELM), Middle Level Management (MLM) and Operational Level Management (OLM). Policy & Strategy matters, Business development & Control and follow-up & standards on the quality of services are taken care of by ELM, MLM and OLM respectively.
All the three levels require Decision Support System to expedite their tasks within budget, in time and other constraints. Therefore, each category of the enterprise structure has technical and business support for services they require either from fully or partially automated systems or otherwise. Service is expected from within the company that could be even internal payables and outside of the company that is definitely out of pocket payables.
For providing the various services, different technological infrastructure has been in place. And in each of the divisions different information systems are operational as identified in the scope of work. These applications share some common business functions, business processes and policies such as data access controls. The data access layer manages the communication between data entry front-end and the database using the security component. This would have been a data access object or a service as a pattern throughout the enterprise. In addition persistence operations and searching methods are implemented for every application independently [5].
The Data Manipulation or Control Languages can be shared and designed for every service. This is an instance of Software as a Service, missing in the existing applications, that permits and could be enabled depending on the privilege of users group. In the same way Application and Infrastructure as a Service is missing that could be again exploited within the enterprise. This is further explained using the efficiency and other metrics [4, 6-7].
The enterprise also receives requests on variety of services from various customers. All types of demands are coming from inter-enterprise and intra-enterprise. Inter-enterprise requests occur from management at all levels, instructors, active students, office announcements, career center, resource planning and scheduler, supervisors and clients. While intra-enterprise requests come from ex-clients, ex-students, external users like universities, employers, families, standard agencies, and others requesting for recommendations and certifications.
The enterprise has solved the system development problem using structure and object oriented methodologies which have introduced fragmented islands of applications, duplicated subsystems and in some cases inconsistency of data and information that tackles problem with tactic than by strategic plan. This approach has resulted in major problems of IT and Business challenges. It has incurred expensive infrastructure and require Service Integration & Standard, implementation of corporate wide governance of security and flexibility for new business processes accommodation.
Therefore, the systems solution should have adapted to the environment and meet the architecture and design constraints of open architecture for plug & play, scalability, common reuse of service, infrastructure and software knowledge. Although incremental development of systems is observed as there are subsystems and other software elements it lacks sharing the architectural vision and consideration for different points of view of the system.
In this validation process, the development of a system at enterprise-wide and software products for a particular application will be considered from different perspectives. The enterprise requires having the holistic picture from the points of view of the users, developers, interaction with other systems, outsourcing, and infrastructure.
7. As-Is Architecture
The structure required for the company is in place with the division of business functional or units roles and responsibilities in order to embark into its vision, mission and to achieve its objectives. The IT requirement of the corresponding business units is observed in the organizational structure as a support unit to the company. Hence, the data and information requirements of some of the business processes are not automated partly. One of the case in point is the capabilities of research findings and knowledge sharing, management and repository.
The applications running are after thought based on the business requirements or drivers. These high level business functionalities are what become software applications. Business function par say software application is comprises of different business processes and stakeholder [8].
The company has also experienced in some of its activities although not supported in the structure the potential of the IT driven service initiatives. This is illustrated in the facility of intranet mail exchange server to submit assignments, grades by the instructors, request for grade report and the like using the respective systems. All the policies, principles and strategies defined in the company (big picture) are compliant with the business and IT driven initiatives.
8. Enterprise-Wide System Architecture
The overall system architecture which is referred as the “Enterprise System Architecture” is represented by Fig. 4. This is captured to demonstrate the existing infrastructure configuration expressed in terms of hardware (servers, workstations, communication peripherals) and the corresponding software of the company.
Each system runs in its own accord as shown in the overview of the logical viewpoint representation of the key components within the enterprise software system and their interactions. This doesn’t promote reuse, data sharing and information interchange. Since most of the systems are stemmed from the functional structure of the enterprise, support for efficient execution of business faces a challenge.
For instance, if one stakeholder say a student wants to request information from the registrar, she/he needs to login first to the registrar system. In parallel, the same student will be forced to re-login to the library system for requesting another service from the library system.
The stakeholder qualifications are the same but requires independent authorization and authentication by each system than sharing it centrally or virtually. Therefore, central mechanism of enforcing standards and security policy across the enterprise is compromised at the expense of expensively installed infrastructure and potential prone to error or complex design [9].
Fig. 4 Enterprise system architecture.
9. Application Architecture
The enterprise runs a dozens of applications in parallel which are mean to give informative decisions matters at all levels. This is a typical situation in most of the organizations who have implemented IT solutions with non service oriented architectural style in place. Such type of architecture style or pattern is something technically reflects the holistic view of enterprise architecture.
This is the case with IT practitioners and business managers in most cases business and IT architectures owned independently. Likewise, infrastructure would have been organized easily having common platform, i.e., Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). Infrastructure architecture viewpoint is depicted in Figs. 5-6 to visualize the resource required and consumed by Student Record Management and Course Management applications as instances [8-10].
The applications are designed with the traditional software architecture approach that supports modular development of systems. Some of the applications are designed using a 3-tier or layered architecture, i.e., with distinct layers for presentation (User Interface), business logic and data access and others with n-tier i.e. web based interface [11].
Fig. 5 SIS infrastructure architecture.
Fig. 6 CMS infrastructure architecture.
10. To-Be Architecture
Service Oriented Enterprise assumes service as a working smaller unit application aligned with the business driven requirements of the enterprise. In service driven enterprise—Business, Application, Infrastructure and Information models are inseparable at a lower end. The “AS-IS” and “TO-BE” states are defined at all levels flexibly.
Software requirements (functional and non-functional) and business objectives are all defined in service requirements. It is unusual to assume IT as a support tool to business process to achieve enterprise-wide goals rather it is a strategic aligns for business competence. It is IT empowered business in a service. It exists autonomously and whose access is through standardized interface contract.
The service architecture applying SOAML (Service Oriented Architecture Modeling Language) for the business domain applications is depicted in Figs. 7-9 as instances. The service architecture modeling language is a standard modeling that encompasses customer and provider service views. Moreover, it serves for the cases of both Business driven and IT driven requirements [9].
10.1 Service Matrix
Vision of the enterprise is discussed in the beginning and reflected by the enterprise Business & IT services visions. The technology vision of each service is designed to have efficient, consistent user experience and business agility. The service business vision is to increase revenue, better ROI and good customer experience. Furthermore each service stakeholder and business processes are left from this paper to make it concise and to the point [12].
The service matrix summarized in Table 1 highlight to capture the percentage of duplication among the overall services throughout the dozen applications delivered to the same stakeholder from varies points of view.
There are 33 unique services (See Fig 10: S01 to S33) supplied for about 10 stakeholders in all the 12 applications running in the company. The analysis and impact of SOEA framework is covered in the following section.
Abbreviations used the application names in Table 1 are EMIS—Executive Level Management Information System; OMIS—Operational Level MIS; IMIS—Instructor MIS; CMS—Course Management System/Moodle; PMIS—Personnel MIS; AMIS—Admission MIS; RMIS—Registration MIS; and SIMS—Student Information Management System.
Fig. 7 Registration service architecture.
Fig. 8 Library service architecture.
Fig. 9 Course management service architecture.
11. Findings from SOEA
As mentioned above analysis based on SOEA design characteristics such as reuse, infrastructure efficiency, duplication and ROI can be derived from the table. However, some of the important lessons learnt and the findings will be highlighted as follows.
Although limited services are considered, compare to entire service exist and anticipated in the company, there are only 21% of the services uniquely serve particular stakeholders. This means that 79% of the services are shareable among stakeholders.
Here, a theoretical challenge among the lesson learnt is the solution architecture implementation should be open architecture and changeable with the concept of service refactoring [13]. The other lesson is the user interface should be easy to use for inexperienced users and enforce standard. There is a probability that a service load could go as high as 93% chances to be requested from any of the points of view. This means that the ability to handle high volume transactions with no performance degradation is one of the service goals that should be attained and worth consideration. This is partly solvable in design and partly in the appropriate infrastructure availability.
The minimum a service occurrence is 17% that requires supporting at least two users concurrently probably at a given time is predictable as seen from the study. This will again demand a meticulous corporate policy implementation and service delivery standard to assure security and data/information integration. It is as well expected to support both distributed and centralized processing capabilities. The last column in the table shows 58% of the applications reuse by sharing almost 100% from the rest of the applications from the enterprise services available.
Fig. 10 Service reuse.
Table 1 Service matrix review.
12. Conclusions
Many organizations have now adopted SOA as an architectural style to help them with architecture, design and implementation of their core services and systems. Most of these organizations are challenged in integrating SOA style with their overall Enterprise Architecture work.
This framework links an SOA style with the EA methodologies to help organizations organize their SOA effort as a key part of their Enterprise Architecture. The case study demonstrates the implementation of architecture goal with organization vision in service oriented organizational structure using services that align Business with IT. The framework is validated as shown in the conclusion Fig. 10 that it has kept the privileges of SOA and EA.
The Y-axis shows the (dozen) applications and the X-axis listed the overall services (S01 to S33) rendered by the corresponding applications. For example S28 can be rendered by one of the nine applications. Likewise when it is summarized: 65% of services are reused, 72% infrastructure efficiency and 51% Faster development time.
References
[1] A. Dico, Addressing enterprise business needs through SOA and TOGAF, in: Enterprise Architecture Practitioners Conference, Austin, 2007.
[2] J. Butler, D. Ellis, Enhancing the Enterprise Architecture with Service Orientation, CBDI Service Oriented Architecture Practice Portal, available online at: http://www.cbdiforum.com/secure/interact/2007-10/enh ancing_enterprise_architecture_service_orientation.php, 2007.
[3] J. Fronckowiak, SOA best practices & design patterns: key to successful service oriented architecture implementation, White Paper Published by Oracle Corp., 2009.
[4] D. Sprott, L. Wilkes, Enterprise Framework for SOA, available online at: http://www.cbdiforum.com/bronze/journal/2005-03/ent_f rame_soa1.php, 2005.
[5] D. Avison, J. Pries-Heje (Eds.), Research in Information Systems: A Handbook for Research Supervisors and Their Students, Elsevier Amsterdam, 2005, pp. 221-238.
[6] TOGAF Version 9 the Open Group Architecture Framework (TOGAF), Document Number: G091, ISBN: 978-90-8753-230-7, Published by the Open Group, 2009.
[7] M. Ibrahim, G. Long, SOA and EA Similarities and Differences.
[8] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 2nd ed., Addison Wesley, 2003.
[9] N. Bieberstein, S. Bose, M. Fiammante, K. Jones, R. Shah, Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap, IBM Press, 2005.
[10] I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2010.
[11] P. Kruchten, Architectural blueprints—the “4+1” view model of software architecture, IEEE Software 12 (6)(1995) 42-50.
[12] L.-J. Zhang, Services Computing: Foundational Discipline of the Modern Services Science, in: 31st Annual IEEE International Computer Software and Applications Conference (COMPSAC 2007).
[13] R. Knippel, Service Oriented EA, Censored Edition, Copenhagen, 2005.