A Conceptual Framework to Analyze Enterprise Business

Solutions from a Software Architecture Perspective

Basem Y. Alkazemi
Collage of Computer and Information Systems
Umm Al-Qura University
Makkah
Saudi Arabia
bykazemi@uqu.edu.sa

Abstract may use Oracle E-Business Suite for their employment

The architectural aspects of software systems are not always management systems while they use Microsoft SharePoint
explicitly exposed to customers when a product is presented to for their website. Others may use PHP for their website
them by software vendors. Therefore, customers might be put at a and SharePoint for their intranet applications in addition to
major risk if new emerging business needs come to light that
Oracle forms for financial and warehousing applications.
require modification of some of the core business processes
within their organizations. So they might need to replace their
Although the variety of technology within an organization
existing systems or re-architect old ones to comply with new is usually unfavorable as far as management is concerned,
architectural standards. This paper describes a proposed this variety might be beneficial to increase flexibility and
framework that helps organizations to build a comprehensive extensibility of the business needs for an organization.
view of their system architecture prior to dealing with vendors. However, it would not be feasible to apply this advantage
Consequently, every organization can have a reference model in practice unless the organization has a solid architecture
that facilitates negotiation and communication with software that describes different layers where every aspect of
vendors. The paper applies the proposed framework to an functionality may fit.
organization in the region of Saudi Arabia to validate its
applicability and generates an architectural design for their
software systems. This paper is designed to draw organizations‟ attention
Keywords: Software Architecture, SOA, ERP, Business Process. within the region of Saudi Arabia towards the importance
of planning for their IT projects from an architectural
perspective in addition to the business needs as that seems
1. Introduction to be the part that is lacking in many IT projects in the
region. It argues that understanding architectural
Many software vendors describe their products from a specifications in addition to the functional ones is
business perspective in a manner to sell only. The only important, especially in cases where organizations need to
things that are described to customers are the functional ensure flexibility, extensibility and consistency of their
aspects of the systems. However, architectural details that systems. Therefore the components of their systems that
express how their system is structured are not explicitly may need to be modified, extended, or replaced can be
defined by vendors. One possible reason for this is the lack identified and managed more practically. This paper
of knowledge regarding software architecture‟s significant describes a proposed architecture for an enterprise system
impact upon business needs. In fact, it is very rare to find and uses this architecture as a framework to evaluate some
an organization that has a plan for adopting an extensible common enterprise solutions in the Saudi Market. We
architecture for their software systems prior to looking for selected Enterprise Resource Planning (ERP) [4] as a
products in the market. They usually look for vendors that system to evaluate against our framework from an
satisfy their business needs within the timeframe and architectural perspective. One reason for selecting such a
budget available to them, with no regard for how these system is that ERP is commonly known as a software
systems are going to be built and what the potential system that manages the different business applications
consequences of adopting a specific vendor‟s technology within organizations. There is no survey in the existing
might be. literature that discusses the dimensions we described in
this paper as the base of comparison between different
Our observation to a number of organizations across the ERP vendors. Most of the surveys are based on attributes
region of Saudi Arabia concluded that many of them such as functional capabilities, usability, cost, technology
employ different technologies in their systems to satisfy a used and customer satisfaction rather than architectural
number of common business needs. For example, some features. Moreover, this paper establishes the basis for
achieving comprehensive alignment between business considering software architecture in software development
improvement and software architecture activities that is as providing support for re-using, evolving, analyzing, and
always lacking among enterprises [17]. managing software. Budgen [12] considered software
architecture to be a way of describing the constructional
The remainder of this paper is organized as follows. aspects of a software system at a high level of abstraction
Section 2 presents a background discussion about software (e.g. design stage). Allen [13] identified architecture as
architecture to set up the context of the work. Section 3 being the vehicle to communicate between the requirement
describes the key quality attributes from a systems and the implementation stages. Szyperski et al. [14]
perspective. Section 4 presents the proposed architectural suggested that architecture is important for establishing a
layer of an enterprise solution. Section 5 discusses the context for software systems representing standards and
main features of a number of ERP solutions in the market. platform requirements.
A case study that reports the utilization of our framework
to generate a system architecture for an organization is Garlan et al. [15] identified a number of architectural
described in section 6. Section 7 presents migration characteristics that might cause a mismatch to occur in
roadmap of UQU systems to comply with our framework. terms of component interaction within a system. These
Finally, the conclusion and possible recommendations are characteristics are:
given in section 8.
 The infrastructure that a component is primarily
built on.
2. Background Review on Software
 Control issues of whether a component can
Architecture generate a control signal or not.
People usually refer to the term „architecture‟ to indicate  The data type manipulated by a system and the
the physical construction of a building in terms of external way it is transferred between components.
shape, and also how the rooms are structured within that
 The pattern of interaction between components.
building. In software, the word „architecture‟ is a term that
is in general use, with a number of different interpretations.  The sequence that components must be instantiated
However, as an analogy to its meaning in civil engineering, and invoked with.
it inspires the meaning of creating a product (a software
system in this case) from a number of selected components Yakimovitch et al. [16] refined the work of Garlan and
rather than building a single monolithic one. So the way identified five variables that describe assumptions about
components must be incorporated, the orders in which they components‟ interactions, namely packaging, control,
must be placed, and the mechanism of interaction between information flow, synchronization, and binding. Their
them, are parts of what a system architecture describes. main motivation was to establish a mapping between
Bas et al. [7] defined software architecture as the structure architectural assumptions and a number of problem
of a system that comprises software elements, their domains that conform to certain standard architectural
external visible characteristics, and the relationship types. They demonstrated that the defined variables can be
between them. IEEE 1471 [8] defines software architecture used to abstractly classify different software architectures.
as “the fundamental organization of a system embodied in All of the above-presented work emphasizes the
its components, their relationship to each other‟s and the importance of considering software architecture as a
environment, and the principles guiding its design and vehicle to fully understand the different parts of a system.
evolution”. Jones [9] defined architecture as the structure This can help organizations to fulfill their business needs.
that is composed of components and rules that establish the In fact, considering software architecture is significant to
basis for the interaction between them. All the definitions organizations as it helps them to identify whether or not a
agree that architecture is concerned with the constituting functional component can be seamlessly integrated into
parts of a system and the relationship between them. their system without interrupting their daily working
routine. In addition, the system must be able to
In the literature, many of the available works have accommodate possible growth in an organization‟s
explained the significance of considering architecture in business. As a result, a number of attributes must be
software systems. One reason for considering software satisfied by software systems to ensure the readiness of
architecture is to help our understanding of complex such a system as the business grows. The next section
software systems. Shaw and Garlan [10] suggested that discusses a number of key quality attributes that establish
architecture can be used to define the overall design of a the context for evaluating a vendor‟s solutions.
system. Garlan and Perry [11] identified the benefits of
3. System Quality Attributes of integration between different systems that
conform to a standard interface.
In the context of software engineering best practices, an  Integration mechanism: applications need to
enterprise software system must satisfy a number of key expose their standard interfaces in a layer within
quality attributes that will ensure its readiness to the overall environment where reaching them can
accommodate new business needs without affecting its be facilitated. This is usually referred to as a
overall software architecture. So, a system adhering to mediator platform where requests can be managed
these attributes can be considered a healthy system to in terms of scheduling, routing, and finding of
accommodate emerging business needs. These attributes applications, among other things.
include:
 Authority matrix: a system might be accessed by
many users, and everyone has their own privileges
 Reference schema: tables in the database must be
to execute specific functionality. This is a
prioritized based on the main business objectives
mandatory attribute that any enterprise system
of the organization. For example, the human
must effectively handle and manage.
resources (HR) schema is usually the primary asset
in most organizations. So any application must be  Data warehouse: some organizations may have
linked to this schema in order to provide services multiple databases for different types of
to the corresponding employee. application. This may increase the administration
and maintenance overheads. Moreover, this may
 Applications decoupling: every application must
conflict with the strategy adopted by the
provide only its basic functionality without mixing
organization that needs to integrate their scattered
its concern with other application business. In
systems. A single unified data source must
addition, applications must not be aware of any
therefore be employed that wraps all the different
other applications in the system. Their main task is
databases and exposes a single interface to the
to receive requests, process them, and provide
applications. This approach is advantageous in the
results. So, any hardcoded links between
case of having various database types (e.g. Oracle,
applications must be eliminated.
SQL, MySql).
 Application architecture: applications must be
well structured in the sense that their composing
To the best of our knowledge, these attributes are the most
components can be identified and the relationship
between them is defined. The architecture of the significant ones that organizations must consider when
application can then be utilized to identify the defining their system architecture. The identified attributes
computational components from the data and are the main driver for establishing our proposed
control exchange components. architectural framework, which is given in the next section.

 Separation of concerns: the functional components

of an application must be distinct in the sense that 4. Proposed Enterprise System Architecture
their business logics are not interleaved. For
instance, credential check functionality must not be One key driver for establishing our framework is the
mixed with data retrieval or computation algorithm representation of workflow within a software system.
functionality. Every concern must be separated in a Currently many systems develop their business processes
modular way (i.e. component) so it cannot be hardcoded into the source code. So, whenever new
confused with other functionalities of an business processes are required to be implemented the
application. overall code must be modified. Moreover, applications are
 Standardization of interfaces: software integrated in a one-to-one manner by writing glue code to
applications must be wrapped in a way that establish the integration. This glue code is usually written
complies with the standard interface used across as a mediator between two applications. Although this
the various systems within an organization. The approach might look simple to some developers, it causes
interface usually defines the standard data process design to become totally confused and mixed. In
exchanging model and control topology that is some cases glue code is injected into one of the
common to all systems. applications themselves. This worst scenario as it will
 Dynamic binding: this attribute needs to be result in very tangled code that cannot be managed over
satisfied in enterprise systems where software the years.
applications can be used differently as per process
design. In fact, this feature promotes a wider level
Our proposed framework considers SOA [5] as an discovery and interaction. It defines the policies
integration facilitator mechanism and not as a service that comply with the standards adopted by
delivery mechanism. The framework is composed of vendors. For example, web services interact by
different layers that, we believe, any enterprise solution in exchanging SOAP messages over HTTP protocol.
the market must satisfy in order to ensure flexibility and Any interaction between services must be
extensibility of their systems. Figure 1 presents our accomplished through this layer. This is usually
proposed architecture for an enterprise solution. referred to as the Enterprise Service Bus (ESB)
layer.
 Orchestration Layer: this layer defines the
Policy Layer business processes that are employed by an
organization. It is responsible for establishing the
Orchestration Layer
sequence by which services are going to be
invoked to satisfy business requirements. For
example, an attendance service might need to issue
Communication Layer a request to a finance service to deduct a certain
amount from an employee salary.

Exposure Layer
Policy Layer: this layer is responsible for defining
the privileges for accessing services. A different
Business Layer level of access rights can therefore be granted at
this layer according to the defined policy.
Data Access Layer

The identified layers are not interchangeable as they must

build up in a bottom-up manner. So, for example, a
Fig. 1 Architectural Layers of Enterprise Solution database can be established and tables created for an ERP
system. Then, a number of standalone applications are
Each layer is independent of the other surrounding layers developed on top of these tables to utilize the data in the
in terms of their main functionality. The description of tables. These applications must then be exposed in a
these layers is as follows: standard manner in order to facilitate their integration with
other applications to achieve new business needs. So the
 Data Access Layer: this layer is responsible for new exposed interfaces are pooled and made ready for
managing the interaction between application and requests. Workflows can then be defined on top of the
database and hiding the databases used in the
available pool of services in order to integrate different
organization. So, if different database technologies
applications seamlessly without affecting each
are used (e.g. SQL, Oracle), this layer will manage
the connectivity with the corresponding source. application‟s concern. In fact, a workflow defines the
design of a system where different components can be
 Business Layer: this layer is responsible for executed in a pre-defined sequence. Once all the business
executing the basic functionality that represents an requirements are established (i.e. all functionality is
organization‟s business needs. In the context of an implemented), there should be privileges assigned to
ERP solution, this layer represents the fundamental personnel who are authorized to execute certain processes
modules offered by the solution such as HR, in the system.
Finance, Projects, and Sales. Every one of these
modules must be a standalone application that is
not aware of any other modules. 5. ERP Solutions Analysis
 Exposure Layer: this layer is responsible for
exposing the available applications from the A number of well-known ERP solutions are available
application layers into services (e.g. web services, nowadays in the market. Oracle, for instance, is among the
com components). All applications are therefore prominent vendors in this field through their Oracle Apps,
decoupled from their underlying environment and or the E-Business suite (EBS) [1]. Oracle ERP is a three-
made available through request-response tier system that is composed of four basic modules, namely
interaction mode. Human Resources, Project Management, Finance, and
Asset Management. These modules are built on top of a
 Communication Layer: the integration layer is
unified Oracle database. The interaction between these
responsible for establishing the communication
modules is achieved via the Business Event System (BES)
pattern and routing protocols that enable service
that triggers message creation or consumption of any
registered parties. Oracle currently offers an additional represents a tiny application, namely sapgui.exe, that is
package, namely the SOA suite, which can be integrated usually installed on the client's machine. The application
with the E-Business suite in order to promote enhanced servers, namely SAP Netweaver, host different SAP
scalability. ERP applications can therefore be exposed on services that execute code written in APAB/4 language. A
the Oracle Service Bus (OSB) as services. These services messaging server is responsible for routing requests
then interact with each other through a business process between applications and establishing a means of
design defined in BPEL. Recently, the key features of the interaction between them. The main modules exhibited by
SOA suite became an integral part of the Oracle E-business SAP ERP are: Financials and Controlling (FICO), Human
suite R12.1 package with the inclusion of the Oracle EBS Resources (HR), Materials Management (MM), Sales &
adapter which exposes pl/sql as services. However, these Distribution (SD), and Production Planning (PP).
added features are sold with different licenses which can
be very expensive to some organizations, especially those It is apparent from the above that all the described ERP
in the government sector. solutions provide similar kinds of functionality and also
they share a common three-tier architectural pattern. The
Microsoft offers a number of ERP solutions to suit various three-tier architectural pattern can satisfy, to some extent,
customer needs, one of which that is known as a the scalability requirement we described earlier; however,
comprehensive solution is Dynamics AX [2]. It employs it is not very efficient in terms of integrating services or
the three-tier architectural pattern, namely, client tier, applications. Currently, the business logics are
Application Object Server (AOS) tier, and database tier. implemented in the application tier in all the ERP
The client contains forms and reports code. AOS is used to solutions. In Oracle ERP, some business logics are stored
execute application objects such as classes and queries. on a database as well. So when there is a need to integrate
The database is normally used to store data for the ERP. two or more applications or services together, there is a
Microsoft Dynamics AX utilizes the Application need to either modify part of the application's code or write
Integration Framework (AIF) to facilitate the integration of an additional mediator application that establishes the
application-to-application and also business-to-business. linking between the corresponding parties. Therefore, our
AIF supports the creation of generic web services and also proposed solution to integrate workflow business in the
document services; it also facilitates the consumption of context can tackle this problem and solidify the application
external web services from within Dynamic AX. Another layer. Moreover, it can satisfy the scalability and
ERP solution provided by Microsoft is the Dynamics GP, integration requirements identified earlier. The mapping of
which is also based on a three-tier architectural pattern. these solutions to our framework is given in Table 1 below.
The application tier is composed of three main
components: the Dexterity tool and runtime, Dynamics Table 1: ERP solutions analysis
Application Dictionary, and SQL server. The Dexterity
tool is used to build the forms and also to attach scripting Layer Oracle Microsoft SAP
code using sanScript to applications. The Dexterity ERP Dynamics R/3
runtime environment is used to enable the execution of a Data source × √ √
functioning application to end-users. This tool is therefore Business √ √ √
implementation
responsible for the development and the execution of the
application interfaces. The Dynamics Application Exposure × × ×
Communication × × ×
Dictionary (DAD) is responsible for storing the business
Policy √ √ √
logics in common component architecture such as COM+
Orchestration × × ×
and DCOM [6], so other distributed applications can use
them as service providers. The main design consideration
of this dictionary is to separate the presentation logic from The Oracle ERP does not adopt the principle of data
the actual business logic of an application, so services can source where different types and technology of databases
be accessed independently of any form or application of can be used, as it is restricted to its own technology
the presentation layer. The workflow engine is not part of platform. This is not the case in Microsoft Dynamics and
the overall structure but Dynamics utilizes SharePoint to also in SAP R/3 as the database link layer is developed to
provide this feature. manage interconnectivity with any type of database
servers. None of the ERP products adopt the notion of
SAP ERP [3], known as SAP R/3, is another prominent services where they decouple business logics from the
solution in the market. It is primarily based on a three-tier underlying environment. Currently every application must
architectural style: the presentation layer, the application be written in a specific programming language that sticks
layer, and the database layer. The presentation layer to certain architectural specification. This adds extra
overheads when there is a future need for potential and faculty members in the University. Moreover, with the
development. All the three ERP solutions lack a well- pioneering e-government movements within the region of
defined integration and communication layer that is Saudi Arabia, it becomes necessary that organizations
responsible for managing interactions and also finding apply major changes to their systems in order to
services. Microsoft Dynamics has a workflow engine that accommodate these new requirements, one of which is
defines how documents must be flowing within an process automation which solely requires splitting
organization. However, the workflow engine is not functional aspects of an application from the process
designed to facilitate the orchestration and integration of aspects. Currently, modifications to add features to any of
applications or services. the systems are done in an ad-hoc manner where the
application's code is modified to satisfy new business
It is obvious that all the ERP solutions focus mainly on the requirements. Specifically, business processes are
functional side to satisfy business needs; however, an implemented directly into the forms, confusing the
architectural arrangement to support scalability and functional aspects of an application with the non-functional
flexibility is not considered in the original building block ones. As a result, the complexity of UQU systems builds
of the system. These additional capabilities can be up rapidly in a manner that will become very hard to
obtained for an enormous additional cost even though they manage in the near future.
play a significant role in enhancing the scalability and
flexibility of software systems within organizations. Our analysis of the main technologies used at UQU
revealed that it currently has three different environments:
SharePoint, PHP, and Oracle. Our proposed architecture is
6. Case Study meant to integrate all systems regardless in a technology-
neutral manner. The proposed system architecture for
We selected Umm Al-Qura University (UQU) as a case UQU is given in Figure 2 below.
study for applying our framework as their environment is
somewhat complicated to manage and control. We have
worked at UQU in the IT deanship for more than three SharePoint (Portal)

years. We observed, throughout this period, a number of WWF/BPEL

challenges that hinder the university from fulfilling its Consume
services
mission. Some challenges are related to the functional
capabilities of their systems while the majority relate to the MS-IIS
Web Services
processes and integration of different systems. Therefore,
we decided to apply our study to the benefit of the
university in order to comply with the new emerging Web based Services
business requirements. Oracle ERP Apps (PHP)

Currently, one of the main objectives of UQU business is

to establish a fully integrated environment that supports e-
Data Access
government business needs, so they need to have a
rigorous solution that promotes changes without
interrupting their daily working activities. Umm Al-Qura
University established its information systems in early Active Directory SQL MySQL
ora
1995 to serve around 3,600 employees and nearly 40,000 Server

students at that time. It owns old-fashioned systems based

on Oracle 6i for forms and reports that are built entirely on Fig. 2 UQU‟s Proposed System Architecture
client-server pattern. The major functional systems include
an in-house-built ERP, Student Information System (SIS), The figure illustrates the proposed architecture for
Library Information System (LIS), and Healthcare satisfying the business need of UQU based on the
Information System (HIS). These systems are used today at resources that are currently available to the university. The
the university to serve around 75,000 students and more main objective of this solution is to promote a fully
than 7,000 employees with some enhancement to their integrated environment that facilitates internal and external
functionality. However, software systems at UQU still lack data exchange, in addition to promoting scalability for
many capabilities that become core-requirement nowadays future development. UQU currently owns a full package of
in terms of compatibility with different environments (e.g. SharePoint 2010, an in-house built Oracle ERP solution, a
mobile devices) and also the services provided to students website and a number of services in PHP, and an Internet
Information Server (IIS). In our proposed solution, services must interact with the PL/SQL services
SharePoint is utilized to play two main roles: the web via a defined work flow in order to support
presence and the service orchestration layer where business dynamic binding. So, no code must be used to
processes are defined through windows workflow establish the linkage between services.
foundations (WWF) provided by the SharePoint workflow  The resulted web services must be exposed
engine. Services are exposed to SharePoint through the through Microsoft-IIS that establishes messages
Microsoft-IIS layer where web services are defined. routing protocol between web services. The
Therefore every application must be wrapped and exposed Microsoft-IIS is considered as the service layer in
as a standalone web service that can be consumed by this scenario.
SharePoint. This capability simulates the basic
functionality of an ESB for service integration and  Active Directory must be integrated to the service
layer in order to provide credential check and
management which represent the communication layer for
assign basic privileges to users according to their
integrating the various applications in an organization.
pre-defined profiles.
SharePoint 2010 must work only on an SQL server, hence,
in this solution, we propose using the SQL server for  Utilize the workflow (WF) engine provided by
document flow management purposes without interfering SharePoint 2010 in order to implement business
with the university database by any means. The resulting processes. The implemented WF represents the
architecture should promote a high degree of extensibility main thread of control that establishes the design
and flexibility where different business processes within or for consuming the exposed services. So, services
between departments become composable and fully can be placed and executed in a sequence to fulfill
automated. business requirements.
 The functional interface must be separated from
the architectural interface [19]. So, UQU team
7. UQU Systems Migration Guideline must identifying the business logic such as data
link, connectors, and modules life-cycle control
We referred partially to the SMART process [18] to help code and separate them from the core functional
us examining the feasibility of migrating UQU legacy business logic. This helps to identify the potential
systems into the new SOA based environment. The functional services that can be consumed directly
analysis uncovers a number of activities that need to be by clients and separate them from any supporting
conducted in order to implement the proposed solution, services that may be related to the architecture of
they are: the legacy system.

 Re-factor applications in order to eliminate

The above set of activities describes how UQU can
potential decoupling applications from each other
migrate their current applications to satisfy SOA basic
so everyone can provide its standard set of
functionality without any reference to other requirements. These activities are considered with the
applications in the system. assumption that UQU is going to utilize the current Oracle
application not only as black boxes but as components that
 Extract stored PL/SQL procedures in the Oracle are not going to be modified in further.
DB and wrap them with containers to be exposed
as web services.
 Business logic must be separated from the Oracle 8. Conclusion
forms by following the Model-View-Controller
(MVC) architectural pattern. So, business logics This paper presented our proposed framework to evaluate
can be accessed from different views and not enterprise solutions in the market. The framework is based
restricted to a single usage. This might be achieved primarily on the concept of SOA to define the different
through the migration to the ADF. So, extract the architectural layers. Although this study was limited only
source code from oracle forms and encapsulate to three ERP solutions in the market, these solutions are
them in a well-defined business component (BC) the most commonly known ones in the Saudi Market. The
models that can be invoked directly by forms. paper has drawn organizations‟ attention to the idea of
Thus, functionality that is embedded in forms can investing in the process of defining software architecture
be de-coupled in self-contained components. for their systems in order to generate a reference model to
fit different technology in the market to their business
 Establish the linkage between forms, BC web-
needs. The next step in this research is to implement the
service, and PL/SQL web-service. So, forms can
be hardcoded to invoke BC services. However, BC potential migrating roadmap resulted from this work to
migrate the current systems at UQU to comply with the conference on Software engineering 1999. IEEE Computer
defined framework. Society Press.
[17] ELECTRONIC SOURCE: R. Malveau, Bridging the Gap:
Business and Software Architecture, Part 1, 2004, Cutter
Acknowledgments Consortium,www.cutter.com/research/2004/edge040203.ht
ml, accessed in 2012.
[18] L. Grace, M. Edwin, S. Dennis, and S. Soumya. SMART:
The author would like to thank the IT dean Dr. Fahad Al-
Analyzing the Reuse Potential of Legacy Components in a
Zahrani for supporting and encouraging this work. Also Service-Oriented Architecture Environment (CMU/SEI-
special thanks to Eng. Ashraf Asfour (the head of 2008-TN-008). Software Engineering Institute, Carnegie
Application Development Department at UQU) who Mellon University, 2008.
helped in preparing data used in this research and http://www.sei.cmu.edu/library/abstracts/reports/08tn008.cf
facilitating accessibility to the underlying system m.
architecture. This work would not be possible without the [19] B.Y. Alkazemi, A Precise Characterization of Software
support of Umm Al-Qura University. Component Interfaces, Journal of Software, Vol 6, No 3
(2011), 349-365, doi:10.4304/jsw.6.3.349-365, Mar 2011.

References
[1] Oracle®, Oracle E-Business Suite Concepts, technical Basem Y. Alkazemi is an assistant professor at Umm Al-Qura
report, Release 12.1 Part No. E12841-04, 2010. University (UQU) in Saudi Arabia under the school of computer
[2] A. Luszczak, Using Microsoft Dynamics AX 2009, Vieweg science & Engineering. He obtained his PhD in 2009 from
Newcastle University in U.K. His PhD topic was concerned with
and Teubner, 2010. addressing the complexity of re-using open-source software
[3] V. Kale, Implementing SAP R/3: The Guide for Business components. Basem is currently holding the position of vice dean
and Technology Managers, SAMS, 2000. of IT deanship for e-government at UQU. One of his main duties is
[4] B. Wagner, E. Monk, Enterprise Resource Planning, Course to establish a framework that leads to the integration of all the
Technology, 2008. university software systems in a unified model. He is a member in
[5] T. Erl, Service-Oriented Architecture (SOA): Concepts, the IEEE, SIGSOFT-ACM, and SEI societies. His main research
interests include software architectural patterns, software product
Technology, and Design, Prentice Hall, 2005. lines, Aspect-oriented SE, SOA, and CBSE.
[6] G.T. Heineman, W.T. Councill, Component-Based Software
Engineering: Putting the Pieces Together, Addison-Wesley
Professional, 2001.
[7] L.Bass, P. Clements, R. Kazman, Software Architecture in
Practice, Addison-Wesley, 2003.
[8] ISO/IEC. IEEE Recommended Practice for Architectural
Description of Software-Intensive Systems. IEEE Std 1471.
2000, Accessed 11 - 2008, Available from:
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=00875
998.
[9] A. Jones, The Maturing of Software Architecture. In
Software Engineering Symposium.1993.Software
Engineering Institute.
[10] M. Shaw, D. Garlan, Software Architecture: Perspectives on
an Emerging Discipline, Prentice Hall, 1996.
[11] D. Garlan, D. Perry, Introduction to the Special Issue on
Software Architecture. IEEE Transactions on software
Engineering, 1995. 21(4): p. 269-274.
[12] D. Budgen, Software Design, second edition, Pearson
Addison-Wesley, 2003.
[13] R. Allen, A Formal Approach to Software Architecture,
PhD Dissertation, Carnegie Mellon University, 1997.
[14] C. Szyperski, D. Gruntz, and M. Murer, Component
Software - Beyond Object-Oriented Programming. 2nd
edition, Addison-Wesley (ACM Press), 2002.
[15] D. Garlan, A. Allen, and J. Ockerbloom, Architectural
Mismatch: Why Reuse Is So Hard. IEEE Software, 1995.
12(6): p. 17-26.
[16] D. Yakimovitch, J. Bieman, and V. Basili, Software
architecture classification for estimating the cost of COTS
integration. In Proceedings of the 21st international