Advanced System Integration and Architecture Course Module

ADVANCED SYSTEM
INTEGRATION AND
ARCHITECTURE
EDDIE D. BUCAD JR
Course Instructor
Batangas State University – The National Engineering University

College of Informatics and Computing Science
BATSTATEU - TNEU Advanced System Integration and Architecture
Foreword
Guided by Memorandum Order No. 325, s.2020 by the Office of the University President of
Batangas State University, this module for Advanced Integration and Architecture was developed
cognizant of the general direction given for the continuous delivery of instruction (1) without
compromising quality and the attainment of Intended Learning Outcomes, but (2) considering
the various contexts of the faculty and students.
Learning became precarious because of Covid-19, but we are Filipinos. And just like the
bamboos in our native land, we bend with the strong wind and to every storm, but our resilience
makes us unbreakable and firm enough to stand again and continue with life.
Zito Red Spartans!
TABLE OF CONTENTS
Course Rationale and Description............................................................................................................................4

Intended Learning Outcomes..................................................................................................................................5
Chapter 1............................................................................................................................................................ 5
Introduction to Enterprise Systems for Management............................................................................................5

Overview of Systems Integration: challenges and drivers.....................................................................................6
Enterprise Systems in Organizations........................................................................................................................6
Enterprise Resource Planning Systems....................................................................................................................8
ERP Implementation..............................................................................................................................................24
People and Organization.......................................................................................................................................31
ERP Vendors.......................................................................................................................................................... 35
Implications for Management...............................................................................................................................40
Chapter 2.......................................................................................................................................................... 43
Requirement Analysis and Modeling....................................................................................................................43
Requirements Determination...............................................................................................................................43
Requirements-Gathering Techniques...................................................................................................................48
Requirements Analysis.......................................................................................................................................... 51
Chapter 3.......................................................................................................................................................... 56
Design Thinking Framework..................................................................................................................................56
Chapter 4.......................................................................................................................................................... 63
Business Rules and Models....................................................................................................................................63
Life-cycle costs.......................................................................................................................................................63
Managing evolution...............................................................................................................................................64
Tracking changes................................................................................................................................................... 65
Maintaining consistency........................................................................................................................................66
Managing multiple models....................................................................................................................................68
Deploying rules......................................................................................................................................................70
Chapter 5.......................................................................................................................................................... 73
Business Rules and Models Continuation..............................................................................................................73
Tools to support rule management.......................................................................................................................73
Business rules management..................................................................................................................................74
Nature of business rules within the organization..................................................................................................75
Repositories and Rule Engines...............................................................................................................................81
Chapter 6.......................................................................................................................................................... 85
XML and Application Integration...........................................................................................................................85
XML, XSLT, and Application Integration.................................................................................................................85
The Value of XML...................................................................................................................................................87
What XML Adds.....................................................................................................................................................91
What XML Does Not Add.......................................................................................................................................92

XML Meets Middleware........................................................................................................................................94
Integration Solutions.............................................................................................................................................95
XML-Enabled Standards.........................................................................................................................................97
Using XSLT for B2B Application Integration...........................................................................................................98
What Is XSLT?........................................................................................................................................................ 99
The Mechanisms..................................................................................................................................................103
Course Rationale and Description
This course studies the process of integrating different systems and software applications by
examining current and emerging trends, strategies, and techniques for developing systems
integration solutions effectively.
Intended Learning Outcomes
ILO 1. Explain key challenges, concepts, drivers, and strategies related to systems integration.
ILO 2. Demonstrate the benefits of the application of an architecture, Rules and Models within a
business environment.
ILO 3. Design and implement feasible website integration with third party software.
Chapter 1
Introduction to Enterprise Systems for Management
Topics
 Enterprise systems In Organizations

 Enterprise Resource Planning Systems
 ERP Implementation
 Project Management
 ERP Vendors
Topic Outcomes
1. Understand the information systems evolution and its historical role in organizations leading
to systems integration and eventually Enterprise Resource Planning (ERP).
2. Learn about ERP systems and their evolution, components, and architecture.
Overview of Systems Integration: challenges and drivers
Enterprise Systems in Organizations

Before delving into the details of ERP systems, we will quickly review the evolution of
enterprise systems in organizations. Business organizations have become very complex. This is
due to an increased layer of management hierarchy and an increased level of coordination across
departments. Each staff role and management layer have different information needs and
requirements. As such, no single information system can support all the business needs. Figure 1-
1 shows the typical levels of management and corresponding information needs. Management is
generally categorized into three levels: strategic, middle or mid-management, and operational. At
the strategic level, functions are highly unstructured and resources are undefined, whereas
functions are highly structured and resources are predefined at the operational level. The mid-
management level is somewhere in between depending on the hierarchy and organizational size.
The pyramid shape in Figure 1-1 illustrates the information needs at each level of management.
The quantitative requirements are much less at the strategic level than they are at the operational
level; however, the quality of information needed at the top requires sophisticated processing and
presentation. The pyramid should assess and display the performance of the entire organization.
For example, the CEO of a company may need a report that quickly states how a particular
product is performing in the market vis-à-vis other company products over a period of time and
in different geographical regions. Such a report is not useful to an operations manager, who is
more interested in the detailed sales report of all products he or she is responsible for in the last
month. The pyramid therefore suggests that managers at the higher level require a smaller
quantity of information, but that it is a very high quality of information. On the other hand, the
operational-level manager requires more detailed information and does not require a high level
of analysis or aggregation as do their strategic counterparts.
Today’s enterprise systems are designed to serve these varied organizational requirements.
Enterprise systems, therefore, are a crucial component of any successful organization today.
They are an integral part of the organization and provide computer automation support for most
business functions such as accounting, finance, marketing, customer service, human resource
management, operations, and more. In general, they play a critical role in both the primary and
secondary activities of the organization’s value chain.
Information Silos and Systems Integration

As organizations become larger and more complex, they tend to break functions into smaller
units by assigning a group of staff to specialize in these activities. This allows the organization to
manage complexity as well as some of the staff to specialize in those activities to enhance
productivity and efficiency. The role of information systems has been and always will be one of
supporting business activities and enhancing the workers, efficiency. Over time, however, as
business changes and expands, systems need to change to keep pace. The result is sometimes a
wide variety of information systems and computer architecture configurations, which creates a
hodgepodge of independent nonintegrated systems. These systems ultimately create bottlenecks
and interfere with productivity.
In today’s globally competitive environment, an organization will find it very difficult to operate
and survive with silo information systems. Organizations need to be agile and flexible, and will
require the same from their information systems. These systems need to have integrated data,
applications, and resources from across the organization. Integrated information systems are
needed today to focus on customers, to process efficiency, and to help build teams that bring
employees together that cross functional areas.
Today’s competitive business is cross-functional, dynamic, and global. Since the early 1990s,
most organizations have tried to remove the functional barriers that had existed for decades. The
business process reengineering gurus and others have convinced management that
compartmentalization is inefficient and ineffective in today’s interconnected world. To compete
effectively in today’s market, organizations have to be customer focused and cost efficient. This
demands cross-functional integration among the accounting, marketing, and other departments of
the organization. This has led to the creation of business units (BU) within organizations that
integrate personnel from the various functional units to work together on a variety of projects
within an organization. Business units are dynamic suborganizations created and eliminated
depending on need. BUs can be in existence for a few weeks or a few years, which makes it
impossible physically to locate the personnel in an adjacent geographical space. This demands
that the information systems be flexible and fluid across the departmental boundaries. In
addition, it requires that systems are accessible anyplace and anytime. These business
requirements ultimately created the need for enterprise systems to support the multifunctional
needs of the organization.
Enterprise Resource Planning Systems
What Is An ERP?
Enterprise resource planning (ERP) systems are the specific kind of enterprise systems to
integrate data across and be comprehensive in supporting all the major functions of the
organization. In this module, enterprise systems are referred to as ERP systems mainly because
the term ERP is more popular and commonly understood in the IT industry. ERPs, shown in
Figure 1-2, are basically integrated information systems that support such enterprise functions as
accounting, financial, marketing, and production requirements of organizations. This allows for
real-time data flows between the functional applications. ERP systems are comprehensive
software applications that support critical organizational functions. As shown in Figure 1-2, they
integrate both the various functional aspects of the organization and the systems within the
organization with those of its partners and suppliers.
Furthermore, these systems are “Web enabled,” meaning that they work using Web clients,
making them accessible to all of the organization’s employees, clients, partners, and vendors
from anytime and anyplace, thereby promoting the BUs’ effectiveness. ERP system’s goal is to
make information flow be both dynamic and immediate, therefore increasing the usefulness and
value of the information. In addition, an ERP system acts as a central repository eliminating data
redundancy and adding flexibility. A few of the reasons companies choose to implement ERP
systems is the need to “increase supply chain efficiency, increase customer access to products
and services, reduce operating costs, respond more rapidly to a changing marketplace, and
extract business intelligence from the data.”
Another goal of ERP system is to integrate departments and functions across an organization
onto a single infrastructure that serves the needs of each department. This is a difficult, if not an
impossible, task considering that employees in the procurement department will have very
different needs than will employees in the accounting department. Each department historically
has its own computer system optimized for the particular ways that the department does its work.
An ERP system, however, combines them all together into a single, integrated software
environment that works on a single database, thereby allowing various departments to share
information and communicate with each other more easily. To achieve this high level of
integration, however, departments may sometimes give up some functionality for the overall
benefit of being integrated.
The central idea behind data integration is that clean data can be entered once into the system
and then reused across all applications.
In summary, ERP systems are the mission-critical information systems in today’s business
organization. They replace an assortment of systems that typically existed in those organizations
(e.g., accounting, finance, HR, transaction processing systems, materials planning systems, and
management information systems). In addition, they solve the critical problem of integrating
information from various sources inside and outside the organization’s environment and make it
available, in real time, to all employees and partners of the organization. We will discuss further
ERP systems and their implications to organizations both before and after their implementation
later in this book.
Evolution of ERP
During the 1960s and 1970s, most organizations designed silo systems for their departments. As
the production department grew bigger, with more complex inventory management and
production scheduling, they designed, developed, and implemented centralized production
systems to automate their inventory management and production schedules. These systems were
designed on mainframe legacy platforms using such programming languages as COBOL,
ALGOL, and FORTRAN. The efficiencies generated with these systems saw their expansion to
the manufacturing area to assist plant managers in production planning and control. This gave
birth to material requirements planning (MRP) systems in the mid-1970s, which mainly involved
planning the product or parts requirements according to the master production schedule.
Later, the manufacturing resources planning (MRP II) version was introduced in the 1980s with
an emphasis on optimizing manufacturing processes by synchronizing the materials with
production requirements. MRP II included such areas as shop floor and distribution management,
project management, finance, job-shop scheduling, time management, and engineering. ERP
systems first appeared in the early 1990s to provide an integrated solution to the increased
complexity of businesses and support enterprise to sustain their compatibility in the emerging
dynamic global business environment. Built on the technological foundations of MRP and MRP
II, ERP systems integrated business processes across both the primary and secondary activities of
the organization’s value chain, including manufacturing, distribution, accounting, finances,
human resource management, project management, inventory management, service and
maintenance, and transportation.
ERP systems’ major achievement was to provide accessibility, visibility, and consistency across
all functions of the enterprise.3 ERP II systems today have expanded to integration of
interorganizational systems providing back-end support for such electronic business functions as
business-to-business (B2B) and electronic data interchange (EDI). From the technological
platform perspective, therefore, ERPs have evolved from mainframe and centralized legacy
applications to more flexible, tiered client–server architecture using the Web platform. Table 1-1
summarizes the evolution of ERP from 1960s to 2000s.
Business Process and ERP
A crucial role of ERP in business, beside integration of functional applications and organization
information, is to better position the organization to change its business processes. As defined, a
business process is a series of tasks or activities grouped to achieve a business function or goal.
For example, order processing may include such tasks as taking an order, checking inventory,
and preparing invoices. Most organizations have a set of policies and procedures to guide their
business process. The ERP software has hundreds of business processes built into the logic of the
system. These processes may or may not agree with the organization’s current business
processes.
An organization has two choices when implementing ERP: change business processes to match
the software’s functionality or modify the ERP software. The consequences of selecting either
option have a long-term impact on the organization in terms of its bottom line and the
performance of its employees, customers, and other stakeholders. Vendors assert that they have
embedded the “best practices or leading practices” of a business process in their software. It is
therefore possible for organizations to maximize their benefits by taking advantage of these best
practices. This occurs only when organizations do not make major modifications to their ERP
software during implementation. In reality, there are other negative consequences for an
organization when modifying the ERP system to match existing processes. For example, any
future upgrades to the system once it has been modified become cumbersome and expensive due
to the fact that the modified system logic needs to be updated separately on every new version of
the software. Thus, every time an organization has to upgrade the ERP system, the IT staff will
have to upgrade the application and upgrade the modifications. Modifications will have to be
reengineered into the system when they are incompatible with the new version.
On the other hand, if the organization decides to implement the ERP system “as-is” (aka. vanilla
implementation), disruptions will occur with the functioning of the organization. Employees,
business partners, and clients will have to be retrained in the new business processes (in addition
to the ERP system). This does generate resistance from the users, adding to the training expense
for the implementation. Thus, management must pay very close attention to the organizational
consequences of modifying or not modifying the ERP software to match their organizations’
business process. This is not an easy decision. A wrong decision can bring down the entire
organization, whereas a right decision can reap enormous benefits. We will later discuss several
ERP implementation examples (e.g., Hershey Foods, Microsoft, and Cisco Systems) that will
highlight the consequences of early management decisions on their organization.
A good understanding of ERP technology and its implementation process can significantly
improve efficiency and effectiveness of the organization’s business processes.
ERP System Components

As shown in Figure 1-3, an ERP system, like its information system counterpart, has similar
components such as hardware, software, database, information, process, and people. These
components work together to achieve an organization’s goal of enhanced efficiency and
effectiveness in their business processes.
An ERP system depends on hardware (i.e., servers and peripherals), software (i.e., operating
systems and database), information (i.e., organizational data from internal and external
resources), process (i.e., business processes, procedures, and policies), and people (i.e., end users
and IT staff) to perform the input, process, and output phases of a system. The basic goal of ERP,
like any other information system, is to serve the organization by converting data into useful
information for all the organizational stakeholders.
The key components for an ERP implementation are hardware, software, database, processes,
and people. These components must work together seamlessly for the implementation to be
successful. The implementation team must carefully evaluate each component in relation to the
others while developing an implementation plan. Hardware, software, and data play a significant
role in an ERP system implementation. Failures are often caused by a lack of attention to the
business processes and people components. Both people involvement and process integration
will need to be addressed from the very early stages in the implementation plan. Staff must be
allowed to play a key role in the project from the beginning. As shown in Figure 1-4, each
component must be layered appropriately and each layer must support the efficiency of the other
layers. The layered approach also provides the ability to change layers
without significantly affecting the other layers. This can help organizations lower the long-term
maintenance of the ERP application because changes in one layer do not necessarily require
changes in other layers.
ERP Architecture
The architecture of the ERP implementation influences the cost, maintenance, and the use of the
system. A flexible architecture is best because it allows for scalability as the needs of the
organization change and grow. A system’s architecture is a blueprint of the actual ERP system
and transforms the high-level ERP implementation strategy into an information flow with
interrelationships in the organization. The ERP architecture helps the implementation team build
the ERP system for an organization. The role of system architecture is similar to the architecture
of a home, which takes the vision of the homeowners with the system components similar to the
wiring, plumbing, and furnishings of a home.
The process of designing ERP system architecture is slightly different from other IT
architectures. Whereas other IT architectures are driven by organizational strategy and business
processes, if purchased, ERP architecture is often driven by the ERP vendor. This is often
referred to as package-driven architecture. The reason for this reversal is that most ERP vendors
claim to have the best practices of their industry’s business processes captured in their system
logic. This argument has proven very powerful in convincing organizations to spend millions of
dollars for the ERP package. In order to leverage this investment and maximize the return on
investment, an ERP implementation is driven by the requirements contained in the package.
The architecture must therefore be conceived after the selection of ERP software, whereas the
architecture is conceived well before buying or developing software in other IT implementations.
An ERP package can have a very different implementation outcome from one organization to
another. In the architecture of a large university, an ERP system can be very complex and must
be designed and tested thoroughly before implementing it in the organization (Figure 1-5).
The architecture sets the stage for modifications or customizations to support an organization’s
policies and procedures, data conversion, system maintenance, upgrades, backups, security,
access, and controls. Many organizations often make the mistake of ignoring the system
architecture stage and jumping directly into ERP implementation because they have planned a
“vanilla” or “as-is” implementation. This can be disastrous because the organization will not be
prepared for long-term maintenance and upkeep of the system.
The two types of architectures for an ERP system are logical (see Figure 1-6) and physical or
tiered (see Figure 1-7). The logical architecture, shown in Figure 1-6, focuses on supporting the
requirements of the end users, whereas the physical architecture focuses on the efficiency (cost,
response time, etc.) of the system. The logical architecture provides the database schemas of
entities and relationships at the lowest tier, followed by the core business processes and business
logic handled by the system at the second tier. The third tier provides details on the applications
that support the various business functions built in to the ERP system. The end users do not ever
see the first and second tiers because they interact primarily with the client–user interface
application tier that provides them access to the functional applications.
e-Business and ERP

Both e-Business and ERP technologies have pretty much evolved simultaneously, since the
1990s. Hence, during the early days, many people thought only one would survive for the long
term. With the initial enthusiasm and support for e-Business, many analysts predicted the doom
of ERP. Instead, both have flourished beyond everyone’s expectation from those early days. One
reason for their success is this simultaneous growth. The early predictions were based on the
assumptions that these two technologies were competing for the same market. Yes, there are
some similarities between the two, namely, both provide platform for systems integration or data
sharing. While e-Business systems are better for sharing unstructured data and collaboration,
ERP are better for sharing structured or transaction data; also, e-Business focus was on external
integration (interorganizational), while ERP systems’ initial focus was on internal data
integration. Therefore, e-Business and ERP are more of complementary technologies (see Figure
1-8) rather than competing technologies as predicted earlier. Norris et al. provide the following
major reasons for this.
1. e-Business technology focus has been on linking a company with its external partners and
stakeholders, whereas ERP focus has been on integrating the functional silos of an organization
into an enterprise application. e-Business technologies that have emerged as successful over the
decade (e.g., business-to-consumer and business-to-business) have generally focused on market
growth by selling products and services to new consumers and markets. On the other hand, ERP
technology has been successful in integrating business processes across the functional spectrum
of the organization and in providing a central repository of all corporate data, information, and
knowledge, thereby increasing organizational efficiency and worker productivity.
2. e-Business is a disruptive technology, whereas ERP is adaptive technology. e-Business
practically transformed the way business operates in terms of buying and selling, customer
service, and its relationships with suppliers. This caused a lot of disruptions in organizational
strategy, structure, power, and the like. ERP has emerged as an adapter by merging the early data
processing and integration efforts within a large corporation. It has been very successful in
aligning and integrating accounting, finance, human resource, and manufacturing technologies
by aligning business processes with information processing logic and in transforming these
organizations from pure hierarchical structures to matrix and other hybrid or flexible
organizational structures. Thus, even though e-Business caused a lot of disruptions in business,
ERP helped these businesses survive by allowing them to adapt quickly to these disruptions.
3. Finally, the early focus of e-Business was on communication (e-mail), collaboration

(calendaring, scheduling, group support), marketing and promotion (Web sites), and electronic
commerce. These can all be considered front-office functions that involve user and/or customer
interactions. In contrast, the focus of ERP systems was mainly on data sharing, systems
integration, business process change, and improving decision making through the access of data
from a single source. These functions can all be considered back-office functions helping the
operational efficiencies of employees, vendors, and suppliers. For example, e-commerce, which
facilitates selling of products online, requires tremendous back-end support, namely, fulfillment
of the online order. This task can be efficient if an organization has an ERP system in place.
The above reasons show why these two technologies have successfully cohabitated in
organizations for the last decade, thereby refuting the earlier claims that one will replace the
other. Even in intranet applications, the functionality is one of ERP applications only, and it is
delivered via Internet-based protocols. Today, both technologies are evolving toward a single
model in which ERP vendors provide e-commerce and e-Business modules as part of the system.
In future, e-business Web site implementation will become a part of ERP implementation.
Benefits and
Limitations of ERP
ERP systems require a substantial investment from an organization in terms of cost, time, and
people. These investments can run into millions of dollars over several years and involve
hundreds of people from the organization. No organization will be willing to invest a huge
amount of resources unless the benefits outweigh the costs. The benefits and limitations of ERP
can be looked at from a systems and business viewpoint; similarly, like other IT projects, the
returns can be tangible and intangible, as well as short term and long term. The management
within an organization that implements an ERP system has to account for the benefits and
limitations of this system from all viewpoints and focus on the big picture to justify the huge
investments in this system to the stakeholders. A strong commitment from management is critical
for the success of ERP systems. This commitment will not be internalized unless a thorough
analysis of benefits and limitations is communicated.
The system benefits and limitations of ERP systems are as follows:

• Integration of data and applications across functional areas of the organization (i.e., data can be
entered once and used by all applications in the organization, improving accuracy and quality of
the data).
• Maintenance and support of the system improves as the IT staff is centralized and is trained to
support the needs of users across the organization.
• Consistency of the user interface across various applications means less employee training,
better productivity, and cross-functional job movements.
• Security of data and applications is enhanced due to better controls and centralization of
hardware, software, and network facilities.
• Complexity of installing, configuring, and maintaining the system increases, thereby requiring
specialized IT staff, hardware, network, and software resources.
• Consolidation of IT hardware, software, and people resources can be cumbersome and difficult
to attain.
• Data conversion and transformation from an old system to a new system can be an extremely
tedious and complex process.
• Retraining of IT staff and personnel to the new ERP system can produce resistance and reduce
productivity over a period of time.
The business benefits and limitations of ERP systems are as follows:

• Increasing agility of the organization in terms of responding to changes in the environment for
growth and maintaining the market share in the industry.
• Sharing of information across the functional departments means employees can collaborate
easily with each other and work in teams.
• Linking and exchanging information in real time with its supply chain partners can improve
efficiency and lower costs of products and services.
• Quality of customer service is better and quicker as information flows both up and down the
organization hierarchy and across all business units.
• Efficiency of business processes are enhanced due to business process reengineering of
organization functions.
• Retraining of all employees with the new system can be costly and time consuming.
• Change of business roles and department boundaries can create upheaval and resistance to the
new system.
• Reduction in cycle time in the supply chain from procurement of raw materials to production,
distribution, warehousing, and collection (see example in Box 1-1).
ERP Implementation
ERP systems are continuously changing and evolving to provide the organization with a new
way of looking at business processes and decision making. Organizations are also continuously
changing to match their environments. Both need the flexibility to adapt with each other in order
to be successful. System implementations are generally very complex, time consuming, and
resource intensive. Because of its size and impact on the organization, an ERP system only
increases this complexity; therefore, before implementing ERP, an organization has to plan and
understand the life cycle of these systems. This section will provide a quick overview of the ERP
implementation process, which begins with business process management (BPM). BPM lays the
foundation for the remaining chapters; the ERP implementation concepts introduced in this
section will be discussed in more detail later.
Business Process Management
Business process management is the understanding, visibility, and control of business processes.
A business process represents a discrete series of activities or tasks that can span people,
applications, business activities, and organizations. BPM is similar to other process improvement
disciplines, such as Lean Six Sigma, which are used by companies like General Electric to
improve organizations’ performance and employee productivity. BPM has a prescribed process
or methodology that should be followed to help an organization document their business
processes and understand where they are being used throughout their business. The initial stage
of BPM is to create an “as-is” process map that defines the current process. The as-is process is
then used as a baseline for determining where the process may be improved. However, simply
documenting the current process does not give the business managers control over the process.
The real value of BPM comes from gaining visibility and control of the business process. BPM
can activate the process, orchestrate the people, data, and systems that are involved in the
process, give the business managers a detailed view into how the process is operating and where
the bottlenecks are occurring, and highlight possible process optimization. Process operational
metrics are automatically collected by the BPM software. Armed with data on how the current
process is operating, business process managers can use various process improvement techniques
to optimize the process. The impact of an improved business process can be realized in many
ways, including improved customer satisfaction, reductions in cost, and increased productivity
by allocating resources to more value-added activities. One way of achieving these
improvements is through implementing ERP system, which has embedded business process
designed to improve employee and organization’s performance. Taking a life cycle approach will
help organizations achieve their process improvement goals with ERP. BPM would be part of
this ERP life cycle.
ERP Life Cycle

Understanding an ERP system life cycle and its effects on today’s organizations is fundamental
to fulfilling the long-term investment in an ERP system. As shown in Figure 1-9, ERP
implementation is not a onetime implementation. It requires a continuous cycle of product
release and support. The key to a successful implementation, therefore, is to use a proven
methodology, to take it one step at a time, and to begin with an understanding of the ERP life
cycle. When a system implementation does not have a well-defined methodology, deadlines will
likely be missed, budgets will be overspent, and functionality will not meet the client’s needs and
requirements.
ERP system implementations are very risky, and using a well-defined project plan with a proven
methodology will assist in managing those risks.
There must be a strong well-communicated need to make the change from the existing
information systems/applications to an ERP system before starting any ERP development or
implementation. There should also be clear and well-defined business objectives written and
communicated to the organization. The project methodology needs to be documented, reviewed,
and fully understood by everyone involved in the project once objectives are outlined.
There are many methodologies documented and used in system implementations. Figure 1-10
shows a sample ERP implementation methodology in which there are five phases of the life
cycle from requirement gathering analysis to stabilization and production support, which are
applied to the three levels of ERP implementation: functional, technical, and organizational.
When selecting a methodology, make sure it is robust and addresses issues at all components and
levels of the enterprise system. If an external implementation partner or consultant is involved,
be sure to review their methodology and determine whether it is appropriate for your
organization. Implementation partners may have good expertise in the functional areas, but their
most important criteria are a knowledge base of how to design and implement systems
successfully.
ERP Implementation Strategies

Implementing an ERP system is problematic without first considering current business processes
and changes to those processes based on the functionality of the new system. If business
processes are not analyzed and compared with what the new system can do, it is very likely the
implementation will require significant system modifications after implementation.
In developing the business case for an ERP implementation one must make a decision on the
number of modifications to be made to address business requirements. An implementation with
considerable modifications to the ERP software package, sometimes referred to as “chocolate”
implementation, can increase the chances of success with the users because the package has been
customized based on user requirements; however, modifications increase the investment in the
system and introduce higher implementation risk.
In a purchased system like ERP, modifying the system means that every modification will have
to be addressed each time the system is upgraded. It is like paying for the modification over and
over again. Most purchased ERP systems today are minimally modified (or as-is) to protect the
investment in the system. This is sometimes called a “vanilla” implementation. Every ERP
vendor upgrades their system on a regular basis, adding functionality, fixing problems, and
generally keeping the product current with the ever-changing technology innovations to remain
competitive. Product life cycles are shown in Figure 1-11.
Software and Vendor Selection

The number of organizations using the Internet has increased dramatically since the early 1990s.
The Internet and Web browsers have created an environment that allows for information systems
to move out of the back room and onto desktops everywhere. Information systems have grown in
functionality and availability. They have also become increasingly complex and difficult to
develop. From the 1960s through the early 1990s many organizations were very capable of
developing an information system application in-house. The development time was not lengthy,
and the systems developed were certainly not as complex. It is very different today. Most
organizations lack the skill-set and desire to spend the time and money developing an ERP
system “in-house.” For many of the reasons identified earlier many more organizations today
have chosen to purchase ERPs on the market.
It is best for an organization that does not have the experience in developing ERP systems to
purchase one; however, it does bring forward several issues that should be addressed. Even
though it may seem that the vendor selection is the most important issue, the key is the
organizational culture. Is the organization ready for change? Organizations need more
preparation for change with a purchased system. Setting expectations, developing organizational
buy-in, and communicating the need for the change are essential. The “old” days of changing a
system within a “silo’d” department are gone. Changing or modifying a system needs to be
addressed in the context of the whole organization. In addition, most organizations that move
from an in-house developed system to a purchased one find they have to address the notion of
system “personality” (i.e., owning the system, its functionality, and how it works). In-house–
developed systems fit an organization and its business processes very closely. With purchased
systems, each is developed with its own “personality” and requires adjusting to it. To utilize a
purchased ERP system fully requires time to continually learn how the system can work best
within the organization.
ERP systems consist of computer applications that support and connect all aspects of an
organization’s business processes and offer a link to customers and suppliers. The data flow
freely and are integrated in “real time.” When an organization realizes that its legacy system is
keeping it from properly and efficiently servicing customers and that their operations are in need
of process improvements, they realize they should consider investing in an ERP system. The
selection of a vendor-developed ERP system is a challenging job because the organization has to
find both a system that is most appropriate for its operational needs and a vendor to become a
“partner” for quite some time.
Before selecting a vendor, the organization must carefully evaluate its current and future needs in
enterprise management systems. This needs assessment can begin very simply by looking at the
size of the organization in terms of the number of employees that will be accessing the ERP
applications. The assessment must look at the industry that the organization belongs to and the
functional areas that the ERP application will be supporting. In addition, it must review the
organization’s existing hardware, network, and software infrastructure and, finally, the resources
(i.e., money and people commitment) available for the implementation. The criteria developed
from this needs assessment can help the organization narrow down the vendors to a select few
(i.e., three or four). These vendors should be invited to submit their bids for the project. During
this phase, vendors should be asked to install their application (sandbox) on the company’s IT
infrastructure and to have it made available to potential users for testing. In addition, the vendor
needs to be evaluated on the following:
• Business functions or modules supported by their software
• Features and integration capabilities of the software
• Financial viability of the vendor as well as length of time they have been in business
• Licensing and upgrade policies
• Customer service and help desk support
• Total cost of ownership
• IT infrastructure requirements
• Third-party software integration

• Legacy systems support and integration
• Consulting and training services
• Future goals and plans for the short and long term
These criteria should help narrow down the selection to one ERP vendor that best fits the
organization. The purchasing and contract discussions should then start with that vendor.
Operations and Post-Implementation

Going live (“Go-live”) is one of the most critical points in a project’s success. A lot of time and
resources have been spent to get to this point. In assessing an ERP project’s readiness for Go-
live, it is vital to focus the efforts of the teams to ensure that task and activities are completed
before going live. This allows project management to address any outstanding issues that may
jeopardize the Go-live date. This involves a readiness process that needs to include as many team
members and appropriate users and managers as possible because it helps the overall
organization understand that the implementation is near and that changes will be taking place.
During a project it seems like the system will never be implemented. An effective readiness
process lets the teams and organization know that going live is close.
Many ERP implementations have turned into disastrous endeavors during or after the Go-live
stage. For instance, FoxMeyer Drug actually collapsed during the stabilization stage, following
SAP implementation, in late 1990s, and filed a $500 million lawsuit against SAP/R3. Much of
the success of the implementation, therefore, is in the stabilization and postproduction support
processes. Stabilization is the time from Go-live to about 90 days after, or until the number of
issues and problems has been reduced. An effective response to stabilization issues will
determine how well the system is accepted by the end users and management. Five areas of
stabilization are important:
1. Training for end users
2. Reactive support (i.e., help desk for troubleshooting)
3. Auditing support to make sure data quality is not compromised by new system
4. Data fix to resolve data migration and errors that are revealed by audits
5. New features and functionalities to support the evolving needs of the organization
Daily and continual monitoring of the implementation issues will provide an appropriate time to
move to the postproduction support phase. This phase also addresses the backlog of development
issues, evaluates new business processes, and provides more updated training, all of which are a
part of the continued implementation.
People and Organization
Project Management
For an ERP system to be implemented successfully, project management must provide strong
leadership, a clear and understood implementation plan, and close monitoring of the budget.
Project management is the glue that holds the project together. Project management must also
follow a process that leads to sound decision making and creates a high level of trust and
accountability with all involved in the implementation.
Figure 1-12 depicts the fundamental balance of project management. Any change to one side of
the triangle will require a change to one or more sides. The role of the project manager is one of
the most exciting yet risky jobs in an implementation. A successful project manager must be
process driven and understand the value of an implementation methodology. The project
manager role is the single most important role in an ERP system implementation. To be
successful one must be prepared to work long hours in a highly charged environment.
A key component to project management is to understand and communicate the ERP system
application management life cycle. The system, whether purchased or “homegrown,” has the
cycle shown (see Figure 1-13). One of the foundations in an implementation is communication
of the different project life cycle phases to senior management and staff. All decisions made
during an implementation phase will have an effect (i.e., cost and staffing) on the application
management phase. The product life cycle application management phase is by far the more
costly phase.
Role of Consultants
Many organizations are quite sophisticated at implementing systems, whereas others only do it
once or twice every 10–15 years. As stated previously, ERP systems implementations are high
risk. It is critical to assess and understand the organization’s capacity for implementing such a
complex system. The costs of failure are great, and the number of failures is much too high. The
development of a credible implementation plan, budget estimates, and deadlines is critical to a
project’s success.
Before trying to implement a major ERP system, organizations must assess their ability to be
successful. There is a model that exists to help organizations understand and assess that ability:
the Capability Maturity Model. This model has five levels of organizational capability, with level
one being the least capable and level five the most capable. If an organization’s assessment
criterion is on the lower end of the model, the organization should look seriously at hiring a
consulting company as an implementation partner to assist and possibly lead the organization
through the implementation.
As stated, it is often the case for organizations without much ERP implementation experience to
use implementation partners. The use of consultants may appear to increase the project cost, but
in most cases it does not. In the case where an organization does have the experience, the need
for consulting should only be considered to address gaps in skills.
Change Management
For major system implementations, the change management role is essential because it prepares
an organization for changes to how its business is done. In implementing any new system,
communicating, preparing, and setting expectations are just as important as training and
supporting the implementation. Effective communication of expectations will reduce risk and
better insure that the system is accepted once it is implemented. Change management was
historically always thought of as important, but it was rarely funded or staffed appropriately.
Today that is changing, and there is an increased awareness that the success of a project is the
result of a well-planned and thorough change management process. Research has shown that
many projects fail due to lack of communication between technical staff and customers, and this
one factor is often cited as a component overlooked in implementations. It is essential to
develop, understand, and communicate the return on investment, business processes, and the
need for change. It is rare that an ERP system implementation failure is based on hardware or
software not working appropriately.
Business Process Reengineering

While the phrase business process reengineering is overused, it is often the case that current
business processes will need to be changed to use the functionality of an ERP system fully. It is
best to make it clear to clients and users that processes will need to be changed, adjusted, or
adapted as the ERP system is implemented. A business process is a group of activities or tasks
that are coordinated for achieving a business goal. A business process can be ordering supplies or
designing a new product for the market. Most organizations have defined policies or procedures
for a business process. For example, in order to buy office supplies the administrative assistant
has to collect order requests from the department members, consolidate them into one order, find
prices from the vendor manuals, fill out purchase order forms, get manager’s approval, and so
on.
The business process task for ordering supplies may not work in the same way after the ERP
system is installed. The way decisions on ordering supplies are made may also change after the
installation of the system; therefore, an organization has to prepare its employees, IT staff,
suppliers, managers, and other affected parties for the arrival of the new system. Global, Ethical,
and Security Management Between the years 1997 and 2007, the IT industry has experienced
massive globalization of its services. Outsourcing and offshoring have become common themes
across all industries when it comes to IT development, maintenance, and support. Whereas large
companies have been outsourcing for a number of years, small and medium-size companies have
only recently come to rely on outsourcing partners for a majority of their IT support.
Globalization has impacted ERP systems in many ways. First, a majority of ERP vendors are
global. SAP, Oracle, Microsoft, and others have support offices and development teams spread
around the globe. Second, large ERP implementation consultants have global offices and staffs to
help clients in ERP implementation projects all over the world; several consultants are emerging
from countries like India. Finally, software leasing or Software as a Service (SaaS) is an
emerging model for outsourcing for many companies that do not want to invest large amounts of
money on in-house ERP implementations.
Ethics and security are other areas that have attracted a lot of attention. There has been a
widespread increase in corporate white-collar crimes such as unscrupulous accounting and
marketing practices, privacy violations, unauthorized data sharing, spam mail, viruses, snooping,
phishing, and identity theft. All these unethical practices have indirectly impacted ERP systems
due to their centrality in organization and direct integration with the database. Compliance
management due to such regulations as the Sarbanes–Oxley (SOX) Act and the Health Insurance
Portability and Accountability Act (HIPAA) are fast-growing software support areas, and several
ERP vendors have started providing software modules or tools to support compliance
management.
Along with additional modules, organizations are implementing security services to manage
access and control in ERP systems, and they are developing awareness programs across their
organizations to help staff and management understand the seriousness of security breaches
within an ERP; however, security unfortunately remains an afterthought. The seamless

integration of ERP software only increases the risk of both hackers who break through perimeter
security and insiders who abuse system privileges to misappropriate assets through acts of fraud.
The ERP world requires a new way of thinking about security, namely, about business
transactions that inflict financial losses from systems-based fraud, abuse, and errors, and not just
the bits and bytes of network traffic.
ERP Vendors
The ERP software market has experienced tremendous growth in the last decade, even after
analysts had predicted its early demise in 1990s. The Global Industry Analysts, Inc.,7 analyzed
ERP software market worldwide (North America, Europe, Latin America, Asia, and rest of
world) by revenue and application type. They predict that world market for ERP software will
reach $67.8 billion by the year 2015, dominated by North America and Europe, from the $36
billion in 2008. Tight budget amid the global economic crisis forces the enterprises to remain
more accountable toward spending on business process and applications. The focus has now
shifted toward reducing the operating costs, implementation time, and the cost of maintenance of
the ERP system. In turn, the vendors too are concentrating on the smaller projects that result in
quick returns, rather than on longer ones with higher implementation periods and delayed
payments. In turn, the enterprises are now opting for single application systems over multiple
systems, in order to save on costs and bring in more functional efficiencies.
Key players dominating the global ERP software market include ABAS Software AG, CDC
Software Inc., Consona Corporation, Epicor Software Corporation, Industrial and Financial
Systems AB, Microsoft, NetSuite Inc., Oracle Corporation, Plex Systems, Inc., QAD Inc.,
Ramco Systems, The Sage Group plc, SAP AG, Unit 4 Agresso NV, and Visma AS, among
others. This vast market can be grouped into three tiers as shown in Table 1-2 below. Tier I
includes large vendors like SAP, Oracle, and Microsoft, who provide support for large
companies; Tier II includes vendors supporting the midsize companies; and Tier III vendors
support small companies. Recently, the midsize and small company markets have shown
tremendous growth. Small companies, which usually have less than 30 users and less demanding
needs, prefer using Tier III software. Midsize companies (with less than 100 users) that have
outgrown Tier III packages often become Tier II clients. They usually have just a few localized
sites and prefer short-term investments. Tier I software is targeted for a large enterprise company.
Here is the market share vendor between Tier II and top three Tier I vendors.
Key Vendors
The competition among ERP vendors has become fierce, and mergers and acquisitions have
become the latest trend. The key ERP vendors (i.e., SAP, Oracle, Microsoft, and Infor) are likely
to hold on to their 46 percent of the ERP applications market. Many organizations who are
shopping for a system will opt for a vendor who is a leader in the industry, whereas others take
the time to examine products from many vendors before making a decision. The ERP industry is
continually changing and evolving as more and more businesses have started using packaged
solutions to support their enterprise functions. The following is a brief description of the current
major ERP vendors.
SAP
Founded in 1972, SAP is the recognized leader among ERP vendors, claiming the largest current
market share. Its solutions are for all types of industries and for every major market. SAP is
headquartered in Walldorf, Germany, with 12 million users, 88,700 installations, and more than
1500 partners. It employs more than 32,000 people in more than 50 countries. Its products
include mySAP Business Suite, SAP NetWeaver, and solutions for small and midsize companies
(e.g., SAP Business One and SAP All-in-One) (www.sap.com).
ORACLE
Oracle technology can be found in nearly every industry around the world and in the offices of
98 of the Fortune 100 companies. Oracle is the first software company to develop and deploy
100 percent Internet-enabled enterprise software across its entire product line, which includes
databases, business applications, and application development and decision support tools. Oracle
provides solutions divided by industry category and promises long-term support for customers of
PeopleSoft, which was acquired in 2004. They have 40,000 professionals, working in more than
100 countries around the world. Their three business principles are Simplify, Standardize, and
Automate. Oracle is headquartered in Redwood Shores, California (www.oracle.com).
INFOR
This company is the world’s third-largest provider of enterprise software, with approximately
$2.1 billion in revenue. It delivers integrated enterprise solutions in supply chain, customer
relationship and supplier management, workforce, asset management, product life cycles,
operational and business performance, and more. Headquartered in Alpharetta, Georgia, Infor is
the tenth-largest software company in the world with 8,100+ employees, 70,000 customers, and
offices in 100 countries worldwide (www.infor.com/infor).
MICROSOFT Formerly Microsoft Business Solutions or Great Plains, Microsoft Dynamics
(MD) is a comprehensive business management solution built on the Microsoft platform. MD
integrates finances, e-commerce, supply chain, manufacturing, project accounting, field service,
customer relationships, and human resources. The key benefit of MD is that users across your
organization can use skills and products that they already know (e.g., a Web browser, Microsoft
Office System products, and Microsoft SQL Server) to access and communicate information
managed within the system. Another benefit of MD is vertical integration—Microsoft strategy is
to provide an ecosystem of software on back office and front office for an end-to-end solution. In
addition, MD is easy to deploy and configure (www.microsoft.com/dynamics).
LAWSON
Founded in 1975, Lawson provides industry-tailored software solutions that include enterprise
performance management, distribution, financials, human resources, procurement, retail
operations, and service process optimization. Lawson is headquartered in St. Paul, Minnesota,
and has offices and affiliates serving North and South America, Europe, Asia, Africa, and
Australia (www.lawson.com).
SSA GLOBAL
SSA Global acquired Baan in 2004 and doubled the company’s size globally. They claim to offer
solutions that accomplish specific goals in shorter time frames and are more efficient with time.
SSA Global is headquartered in Chicago, Illinois, with offices all over the world
(www.ssagt.com).
EPICOR
This company provides enterprise software solutions for midmarket companies around the world.
The company claims to have solutions to a variety of needs, whether a customer is looking for a
complete end-to-end enterprise software solution or a specific application. It provides solutions
for a limited number of specific industries, including nonprofit, distribution, manufacturing, and
hospitality. Epicor is headquartered in Irvine, California (www.epicor.com).
The ERP market has matured to a point where heightened competition has brought declining
sales. As a result, ERP vendors are committed to bundling new functionality (e.g., CRM, SCM,
and Compliance) to provide more value to their customers.
Software Extensions and Trends

In the mid-1990s, during the Internet and dot-com boom, many IT experts predicted the doom of
ERP systems because virtual organizations, or e-Business, would eliminate the need for ERP. The
focus of ERP has always been on supply chain management, and organizations were turning to
Internet and Web-based technologies to accomplish this task. After the initial rush for Web-based
supply chain software, however, with vendors like Siebel, i2, Ariba, and Commerce One,
providers of best-of-breed point solutions that were powering SCM for e-Business, these new
applications lost their luster due to lack of comprehensiveness of the applications. As e-Business
firms started growing bigger with advanced needs in HR, accounting, and warehousing, the non-
ERP vendors were not able to support their requirements. At the same time, ERP vendors were
starting to expand their functionality to the Internet and e-Business. For example, SAP
introduced mySAP.com and PeopleSoft introduced a three-tier Web-enabled client for
accessing all their modules via the Internet. In addition, there were several third-party software
integrators like Extricity and Neon that linked the Internet to ERP applications. Intense
competition and fluctuating sales have forced the ERP vendors to expanding their software
functionality to add value and to support new organizational needs from compliance
management, customer support, global supply chain, and such emerging technology platforms as
open-source software (OSS) and service-oriented architectures (SOAs). Open source addresses a
key concern in this instance. ERP vendors often pitch packaged applications to smaller
enterprises that they can run as is, requiring little or no IT investment. It’s a logical pitch in
environments with scarce technological resources, but a substantial percentage of smaller
companies want or need to customize the applications to fit their specific business needs, much
like larger enterprises.
Another trend among big vendors has been the expansion of their software market for small to
medium-size businesses. The saturation of the demand in big business and the lucrative nature of
the small and midsized business markets have led vendors like SAP and Oracle to enter the small
business market, which was originally the target of Microsoft and Epicor. For example, Oracle
Corp. and its development partner NetLedger Inc. are providing hosted software suites for small
and midsize businesses. NetLedger’s NetSuite provides portal views into a suite of applications
geared for smaller companies. SAP similarly launched its CRM on-demand solution for its small
business customers. A Gartner Group study found that attracting and retaining new customers
will be the No. 5 business priority for organizations.
Similarly, SOA implementation will continue to grow as a factor in ERP purchase decisions
because vendors are using creative marketing around product strategies versus buying what is
currently available. Vendors are making their pitches with a subliminal message: “If you want to
stay current with the rush toward SOA, you need to be on our platform.” Another shift is toward
recurring and variable revenue models—with maintenance charges driving industry growth—
companies like Oracle earn about 50 percent of their revenue from maintenance. Finally, the
other major revenue shift is toward software as a service or hosted subscription-based
application.
Although this strategy is causing difficult adjustments for the big vendors, they are adjusting
their pricing models so that they can get incremental license revenue through higher levels of
usage. Looking ahead, social networking and open-source software solutions are poised for
significant growth. For example, Facebook has become the number one social network software
worldwide in 2010, with 500+ million users and growing. Soon, we may see an integration of
socialnetworking system with ERP systems. Similarly, open-source software vendors, like
Compiere (www.compiere.com) and OpenBravo (www.openbravo.com), have emerged by
focusing on reducing the total cost of operations (TCO) of ERP implementation and by enabling
high-level customization due to access to source code, which is not possible with traditional ERP
software.
Implications for Management

Managers implementing ERP systems in their company should remember the following:
ERP systems implementation is a complex organizational activity. Mistakes will be made in
any ERP system implementation, and these will usually not be on technology. It is important to
evaluate and learn from the successes and failures. As described in the examples in this chapter,
the difference between success and failure is sometimes very small. Managing risk is all about
keeping project focus and clear communications throughout the organization. For example,
ComAir had major problems with their merger with Delta Airlines because they had not
upgraded their legacy customer and financial systems. Replacing legacy systems with a new ERP
system is a very high risk, but, as Comair found out later, the cost of not replacing an aging
system can be greater. The lesson to learn here is that managing risky endeavors is instrumental
to business growth and success. IT systems are critical to a company’s daily business. If Comair
had clearly understood the problems they were facing, their decision to migrate to a new system
would have saved the company customer service and financial problems. In the case of UMass
Amherst, not fully testing the system under a heavy load created a great amount of confusion on
campus.
ERP systems implementation requires strong project management oversight. ERP
implementation projects must be continually evaluated for project status, effectiveness, and risks
to the organization. Large ERP implementations often require external assessments done on a
quarterly basis to help identify and address project risk areas and minimize failures. Older
management styles and structures are not as effective in today’s organizations. Current
management styles need to be collaborative, creative, and flexible. Managers must be skilled in
developing business models that can fully utilize the capabilities of an ERP. Successful managers
will need to have skills both in facilitation and communication and in managing organizational
change.
ERP systems provide improved and added functionality for an organization. ERP systems
create an advantage by strategically cutting costs, increasing profit margins, and growing the
enterprise. Integrated business processes and data also provide for improved strategic reporting
for planning and decision making. The utilization of the Web creates access to new audiences
and customers. Management must develop and communicate a long-term strategic business
vision to determine how an ERP system will change or improve business. It will be difficult, if
not impossible, to bring change to an organization without looking at the organization
holistically.
ERP systems are set to proliferate globally. The globalization of commerce and the Internet
bring the world closer, understanding how these systems work and the effects they will have on
organizations is necessary. Today, even mid-market companies are increasing their international
presence, often driven by major customers who have entered global markets. Every part of the
organization is involved or affected by an ERP system, whether a technical staff person,
functional analyst, or an end user. Small to midsize organizations are realizing the need for a
single integrated system to adapt to the changing environments and needs around the globe. The
proliferation of ERP system implementations continues and will continue at a rapid pace. New
generations of systems will only capitalize on what has been accomplished already.
Organizations successfully implementing an ERP system will not retreat to nonintegrated
systems.
Chapter 2
Requirement Analysis and Modeling
Topic Outcomes
At the end of the topic session, the students should be able to:
1. Create a detailed requirements definition report that lists functional and non-functional
requirements;
2. Use requirements-gathering techniques for collecting information;
3. Analyze the gathered information using requirements checklist; and
4. Create functional models of business processes using use-case diagrams when gathering
and defining system requirements.
Requirements Determination
Systems development or applications development is a systematic process of defining, designing,
testing, and implementing a new application. The four (4) fundamental phases common to all
software development projects are planning, analysis, design, and implementation. In the
analysis phase, all projects require systems analysts or requirements engineer. The role of a
systems analyst is to gather requirements, analyze the gathered requirements, model the user
needs, and create blueprints for how the system should be built.
The first activity of a systems analyst is to determine the user requirements for a new system and
refine them into a detailed requirements definition. The purpose of requirements determination is
to convert the high-level requirements defined from user requirements into a list of detailed
requirements, called requirements definition report, that can be used as inputs for creating
models such as functional model.
A requirement is simply a statement of what the system must perform or what characteristic it
must have. User requirements are determined from discussions with the client and determine
their actual needs. Then, these are refined in the design phase into system requirements that state
the functional and non-functional requirements of the system. During analysis, requirements are
written from the perspective of the needs of the user. In the design phase, the user requirements
will be used to describe how the system will be implemented. Requirements can be functional or
non-functional.
• Functional requirements – These are requirements are directly related to the process a system
has to perform or data it needs to contain. For example, requirements stating that a system must
have the ability to search for available products, report actual and budgeted expenses, or generate
financial statements are all functional requirements. These requirements directly flow into the
creation of functional, structural, and behavioral models that represent the functionality of the
system. Functional, structural, and behavioral models are graphical representations that show
how a system or software works.
• Non-functional requirements – These requirements pertain to behavioral properties that a

system must have, including operational, performance, security, and cultural and political. These
requirements define how a system or software is supposed to be or its system properties.
 Operational requirements – These specify the operating environment(s) in which the

system must perform, as well as how these might change over time. These usually refer to
operating systems, system software, and information systems with which the system must
interact. These might also include the physical environment, such as in what building area
the system must be installed. For example, the system of a company must work over Web
environment with Web browsers, or the system must be able to work with different
operating system platforms such as Linux, Windows, and Mac OS.
 Performance requirements – These deal with issues related to performance such as
response time, capacity, and reliability of the system. For example, the system’s database
must be updated in real time, and the system will process and store data on approximately
5,000 customers for a total of about 2 Mb of data.
 Security requirements – These address issues with security, such as who has access to the
system’s data and must have the ability to protect data from disruption or data loss. For
example, only manager levels can change inventory items on the system within their own
department; this way, the system’s data will be encrypted to provide security and files
will be scanned for viruses before saving them on the system to prevent the system from
a potential threat.
 Cultural and political requirements – These deal with issues related to the cultural and
political factors and legal requirements that affect the system. For example, the system
should not use any terms or icons that might offend anyone, the system should use the
English language only, and personal information of customers are not transferrable
outside the country. These also address the issues related to the rules of the company.
Non-functional requirements are used primarily in design when decisions are made about
the database, user interface, hardware and software, and the system’s architecture. Non-
functional requirements affect the decisions that will be made during the design of a
system. These requirements are very important in understanding how the final system
works. Requirements must define the clients’ or users’ needs as well as what is expected
from the software or system. Requirements Definition Report The requirements definition
report, also referred to as requirements specification document, is a documentation that
lists the functional and non-functional requirements of a system in an outline format and
defines the scope of the system or software. This is used to describe what the systems can
do, including its characteristics, and is used as a guide in developing the system or
software. Figure 1 shows a sample outline of the requirements definition report.
Many organizations provide industry standard templates similar to the outline in Figure 1. These
templates may be based on the International Organization for Standardization (ISO) standards,
Institute of Electrical and Electronics Engineers (IEEE) standards, or industry best practices.
Software companies employ these templates or create their own outline based on the industry
best practices. Figure 2 shows a sample of specific requirements for an appointment system for a
typical doctor’s office.
Figure 2 contains both functional and non-functional requirements. The functional requirements
include requirements of how the users—doctor, patient, and manager—will use the system. The
non-functional requirements include requirements that define how the system will operate and its
characteristics. The requirements are numbered in an outline format so that each requirement is
clearly identified. These requirements are grouped into functional and non-functional
requirements, and these requirements include headings to further group the specific
requirements. It is a best practice to include the words “shall” or “will” when writing
requirements like the one in Figure 2. A properly written requirements definition report describes
exactly what the system needs to the analysts and benefits all successive phases of the software
development process such as software testing. When discrepancies arise during software or
system development, this document serves as a tool for clarification.
Requirements-Gathering Techniques
Requirements gathering or requirements elicitation is the process of cooperating with clients or
users to determine what requirements are needed. When determining requirements for the
requirements definition report, the systems analysts need to define how a computer system or
software should operate. They need to help clients or users to discover their needs. They use
requirements-gathering techniques to collect information and list the business or user
requirements that were defined from that information. The analysts then work with the entire
project team and clients to verify, change, and complete the list of requirements that were
identified before moving to design.
The challenge in requirements-gathering is choosing the way(s) on how to collect information.

There are many techniques for gathering requirements. Each technique has its own strengths and
weaknesses, many of which are complementary, so most projects use a combination of
techniques. The five (5) most commonly used techniques are the following:
 Interviews – This is the most commonly used requirement-gathering technique. In

general, interviews comprise interviewers and interviewees. There are five (5) basic steps
to the interview process, which are as follows:
o Step 1. Selecting Interviewees – The first step in interviewing is to create an
interview schedule that lists who will be interviewed, when, and for what purpose.
The people who appear on the interview schedule are selected based on the
analyst’s information needs. The client, users of the system, and other members of
the project team can help the analyst to determine who in the organization can
best provide valuable information about the requirements. These people are listed
on the interview schedule in order when they should be interviewed. Figure 3
shows a sample of an interview schedule.
People at different levels of the organization have varying perspectives on the

system. Therefore, it is important to include managers who manage the processes
and the employee who actually performs the processes in the interview schedule
to gain high-level perspective on an issue.
o Step 2. Designing Interview Questions – There are three (3) types of interview
questions:
 Close-ended questions are those that require a specific answer. These
types of interview questions are used when an analyst is looking for
specific information. An analyst may ask, “How many requests does a
company process per day?”
 Open-ended questions require the interviewee to answer in open text
format where they can answer based on their complete understanding and
knowledge. These types of interview questions are designed to gather rich
information and give the interviewee more control over the information
that is revealed during the interview. The information that the interviewee
discusses uncovers information that is important as the answer. For
example, the analyst could ask the interviewee, “What are some
improvements you would like to see in the new system?”
 Probing questions follow up on what has just been discussed from close-
ended or open-ended questions in order to learn more. These are often
used when the interviewer is unclear about an interviewee’s answer. These
interview questions encourage the interviewee to expand on or confirm

information from a previous response. For example, after the analyst asked
the “What are some improvements you would like to see in the new
system?”, the analyst will ask a probing question “Why do you think those
improvements are necessary for the new system?” These types of
interview questions are usually combined during an interview. Whatever
type of interview is conducted, interview questions must be properly
organized and listed into a logical sequence in a formal list so that the
interview flows well.
o Step 3. Prepare for the Interview – It is important for an interviewer to prepare
for the interview. The interviewer should have a general interview plan listing the
questions to be asked in the appropriate order and should anticipate possible
answers and provide follow-up with them. The interviewer should confirm the
areas in which the interviewee knows so as not to ask questions that the
interviewee cannot answer. Review the topic areas, the questions, and the
interview plan, and clearly decide which have the greatest priority in case time
runs short.
o Step 4. Conduct the Interview – The interviewer should start with an
explanation of why s/he is conducting the interview and explain why the
interviewee is there. The interviewer may proceed into the planned interview
questions and should take notes to record the interview. Recording ensures that
the interviewer does not miss important points an s/he can focus on the interview.
But before doing so, ask the interviewee whether it is appropriate for him/her to
record the interview. After conducting the interview, the interviewer should
briefly explain what will happen for the system.
o Step 5. Post-Interview Follow-up – After the interview, the analyst must prepare
an interview report that describes the information from the interview. The report
must contain interview notes, information that was collected throughout the
interview, and a summary in a useful format. The interview report must be sent to
the interviewee with a request to read it and inform the analyst for clarifications or
updates. The following figure shows a sample interview report.
Requirements Analysis
After gathering data, the requirements analysis is conducted to determine if the specified
requirements are actually required. This is the process which gathered requirements are analyzed
to ensure that those requirements are actually required to solve conflicts that will affect the
designing and development of the system or software.
How to Analyze Requirements
Requirements should be analyzed for the characteristics of good requirements and project teams,
or analysts employ a checklist as a tool to determine if each specified requirement is actually
required. Requirements analysis must be performed by a team including project manager,
systems analysts, developers, quality assurance analysts or software testers, and other relevant
team members. Functional and non-functional requirements should organize elicited
requirements before analyzing them.
Characteristics of a Good Requirement
Requirements are the foundation of the system, and project planning and development is based
on the elicited requirements. Therefore, it is essential that each elicited requirement has the
characteristics of a good requirement. A good requirement should possess the following
characteristics:
o Necessary – The requirement is really needed or specifies an essential factor on the

system. This characteristic defines that if the requirement is removed, a deficiency will
exist that cannot be achieved by other features of the system.
o Unambiguous – The requirement is stated that it should only be interpreted in only one
(1) way. This characteristic defines that requirement is specific and easy to understand.
o Consistent – The requirement should not have conflicts with other requirements. Any
conflicts must be determined, and overlap between requirements must be resolved.
o Complete – The requirement must completely describe the necessary functionality that
will result to meet the user’s need.
o Singular – The requirement statement includes only one (1) requirement with no use of
conjunctions. Requirement statements with conjunctions such as “and,” “or,” and “but”
must be reviewed carefully to see if they can be broken into singular requirements. The
requirement must not contain multiple needs to avoid anomalies and for an analyst to able
to analyze it independently.
o Feasible – The requirement is achievable within system constraints such as time, cost,
legal, and available resources. This characteristic defines that the requirement is possible
to be implemented.
o Verifiable – The requirement is verifiable if the implemented system or software can be
tested to prove that the specified requirement has been met. Different testing tools are
used to prove that the system or software satisfies the specified requirement. Verifiability
is enhanced if the requirement is measurable by analysis, inspection, and test cases.
o Traceable – A requirement is traceable if it satisfies all the other characteristics of a good
requirement, then the requirement must have a unique identifier to trace all changes to it
throughout the development life cycle. An example of a unique identifier for a
requirement can be “REQ001.” Table 2 list the characteristics of good requirements with
examples of bad and good requirements.
These are the standard characteristics that a requirement must have, but project teams can add
other characteristics depending on how they will satisfy the actual requirements needed by client.
For example, a project team can add a characteristic that the requirement must not conflict with
the policy of the company or does the requirement align with the business goals of the company.
Using Requirements Checklist
A checklist is a list of questions which the analyst will use to assess each requirement. Figure 5
shows an example of a checklist used for analyzing single requirement. There will also be as many
completed checklists as there are many requirements to analyze. The checklist must be filled in for each
requirement. All questions must be answered “yes” to ensure that the requirement satisfies the
specified characteristics or questions. All the requirements must be analyzed with the project team, and
the identified deficiencies must be corrected.
Figure 5 shows a simple checklist, but any project teams can create or modify their own standard
checklist that benefits their system or software development. Before analyzing the requirements,
it is important that the team must have their checklist to help them in the analysis process. After
analyzing the requirements, the analyzed requirements must be systematically organized to
create the requirements definition report and must be reviewed by the client for approval.
Creating requirements definition is an iterative process where the analysts or project team elicit
information, analyze the information, then create or revise the requirements definition report.
This process continues, and the requirements definition report contains revisions until the client
approves the document.
Chapter 3
Design Thinking Framework
Topics
 Discover, Design and Deliver

 Journey Map and Demographics
 Emphatize and Ideate
 Creating prototypes
Topic Outcomes
1. Helps organize the information and ideas of a problem so that the team can work on it
more effectively.
2. Practice and facilitate innovation and learning.
Design thinking is a problem-solving and innovation framework that emphasizes a human-

centered approach to address complex challenges. It involves a structured process that
encourages creativity, collaboration, and iterative prototyping. The design thinking framework
typically consists of several stages:
1. Empathize- This stage involves understanding the needs and perspectives of the people you
are designing for. It requires empathy to truly grasp the user's experiences, feelings, and
motivations. Techniques such as interviews, observations, and surveys are commonly used to
gather insights and build a deep understanding of the users.
Empathy in the context of design thinking is about putting yourself in the shoes of the people
you're designing for. It's the ability to understand and share the feelings, thoughts, and
experiences of others. In simpler terms, it's like trying to see the world from someone else's point
of view.
Here are some key aspects of empathy in design thinking explained in a more straightforward
way:
Understanding Feelings:
Imagine you're creating something for a friend. Empathy means you take a moment to
really feel and understand their emotions, needs, and challenges. It's not just about what
they say but also about what they might be feeling.
Active Listening:
Think of empathy as being a great listener. It's not just hearing words; it's paying
attention to the tone, the emotions, and the unspoken things. This helps you get a fuller
picture of what someone is going through.
Observing Behavior:
Sometimes people might not express everything with words. Empathy involves keenly
observing how people behave, what they do, and what might be important to them. It's
like noticing the little details.
Putting Yourself in Their Shoes:
Picture yourself in someone else's situation. What would you feel? What would you
need? Empathy is about imagining and understanding someone else's experience as if it
were your own.
Asking the Right Questions:
Empathy also involves curiosity. It's asking questions that go beyond just facts. You
might ask about someone's preferences, challenges, or dreams to truly understand their
needs and desires.
Designing with Heart:
When you design something with empathy, it's like adding a touch of heart to it. You're
not just solving a problem; you're creating something that deeply resonates with the
people who will use it.
Empathy is the secret sauce that makes design thinking really work. It's about caring,
understanding, and genuinely connecting with the people you're designing for. By embracing
empathy, you create solutions that are not just functional but also deeply meaningful to the
people who will benefit from them.
2. Define - Once you have collected information, the next step is to synthesize it and define the
problem. This stage involves framing the user's needs, insights, and challenges into a clear
problem statement. The goal is to articulate the problem in a way that guides the design process
and sets a clear direction for ideation.
In the design thinking process, the "Define" stage is like putting on your detective hat to figure
out exactly what problem you're trying to solve. It's all about turning a fuzzy idea into a clear and
specific challenge that you can tackle. Let's break down the "Define" stage in a more
understandable way:
Sorting Out the Clues:
Imagine you're solving a mystery. You gather all the information you've got from talking
to people, observing, and brainstorming. Now, in the "Define" stage, you sift through
these clues to identify the main problem. It's like saying, "Aha! This is what we really
need to solve."
Creating a Problem Statement:
Instead of having a vague sense of what needs fixing, you put it into words. A problem
statement is like the mission for your design. It's a clear sentence or two that says, "Here's
the problem we're going to tackle." This helps keep everyone focused on the same target.
Narrowing Down the Scope:
You can't solve every problem in the world, right? The "Define" stage helps you decide
what to focus on. It's like zooming in with a camera lens to get a sharp picture. You don't
want your challenge to be too broad or too narrow; it's about finding that sweet spot.
Making It Human-Centric:
The "Define" stage is not just about any problem; it's about the problems people face.
You humanize the challenge. For example, instead of saying "Improve customer
satisfaction," you might say, "Help busy parents find a convenient and affordable way to
shop for healthy meals."
Setting the Design Direction:

Once you've defined the problem, it's like setting the compass for your journey. It gives
you a sense of direction. Now you know what you're aiming for, and it becomes a guide
for the rest of the design process.
Think of the "Define" stage as the moment when you put your problem-solving goggles on and
say, "Okay, this is the puzzle we're solving, and here's how we're going to describe it." It's a
crucial step because a well-defined problem leads to more focused and effective solutions in the
later stages of design thinking.
In standard design and UX processes, the term "prototypes" typically refers to early, simplified
versions of a product, service, or interface that are created for testing and validation purposes.
These prototypes help designers and teams gather feedback, make improvements, and iterate on
the design before moving forward with full-scale development.
Protopersonas- represent a preliminary stage in creating user personas, the ultimate aim is to
develop comprehensive personas based on solid user research. Personas, whether in prototypical
or final form, play a crucial role in the design thinking process by helping teams keep the end
users in mind throughout the design and development phases.
3. Ideate - In the ideation phase, the focus is on generating a wide range of creative solutions to
the defined problem. This involves encouraging a free flow of ideas without immediate
evaluation. Techniques such as brainstorming, mind mapping, and other creative exercises are
used to stimulate innovative thinking.
Ideation involves the generation of a multitude of ideas, often through techniques like
brainstorming, mind mapping, or other creative exercises. Once you have a diverse set of ideas,
the next step is to evaluate and categorize them to determine which ones are more promising or
feasible. This process helps in identifying potential solutions and narrowing down the focus for
further development. Here's a more detailed breakdown of the process:
Generate Ideas:
Encourage a free flow of ideas without immediate evaluation or judgment. Use

techniques like brainstorming, mind mapping, or other creative exercises to generate a
large number of ideas.
Divergent Thinking:
During the ideation phase, focus on divergent thinking, which means exploring a wide
range of possibilities. Quantity is often prioritized over quality in the initial stages.
Capture All Ideas:
Ensure that all ideas, even seemingly unconventional or "crazy" ones, are captured.
Sometimes, the most innovative solutions emerge from unexpected sources.
Categorize and Prioritize:
Once you have a substantial list of ideas, start categorizing them based on themes,
similarities, or potential solutions. Grouping similar ideas together helps in organizing
thoughts.
Evaluate Feasibility:
Assess the feasibility of each idea. Consider factors such as technical constraints,
resources required, and alignment with the project goals. This evaluation helps in
identifying ideas that are more practical and achievable.
Ideation is a crucial stage in the design thinking process where the goal is to generate a wide
range of creative and innovative ideas. This phase encourages a free-flowing and open-minded
approach to problem-solving.
4. Prototype- Prototyping is about turning selected ideas into tangible representations. These can
be low-fidelity prototypes such as sketches or high-fidelity prototypes like interactive models.
The purpose is to quickly test and iterate on ideas, gathering feedback and refining the solutions.
5. Test - The testing phase involves obtaining feedback on prototypes from actual users. This
feedback is crucial for refining and improving the solutions. It helps in identifying what works
and what needs further adjustment. The testing stage may lead to a reiteration of the entire design
process, with a focus on refining and enhancing the chosen solution.
6. Implement- After successful testing and refining, the final solution is implemented. This
could involve scaling up the project, launching a product, or implementing a new process within
an organization. Implementation also involves considering the long-term viability and
sustainability of the solution.
It's important to note that the design thinking process is iterative, and stages may be revisited as
new insights emerge. Additionally, collaboration and multidisciplinary teams play a key role in
the design thinking framework, as diverse perspectives contribute to more innovative and
effective solutions.
Core Principle of Design Thinking
1. Writing is greater than talking

a. It’s the fastest way to get everybody’s input.
b. Writing keeps everyone engaged
c. Writing minimizes “group think”
d. No debates, questions, discussions, or stories
2. Getting started is greater than being right
a. We won’t truly know until we test our ideas
b. Priority is to accelerate towards testing
c. Test cheaply and quickly
Chapter 4
Business Rules and Models
Topics
 Life – Cycle Costs

 Managing Evolution
 Deploying Rules
Topic Outcomes
1. Examine the problems and alternatives in the cost production.
2. Understand software and business changes.
3. Know the components of testing new systems.
Life-cycle costs
Like many other complex artifacts, an information system follows a life cycle. The system will
be conceived, built, operated, and, eventually, pass into history. There's always a strong
temptation to focus on the early stages of the life cycle, when the system is being defined and
created, because it's here that the system takes on its fundamental characteristics. However, most
of the cost of ownership of the system is incurred during its operational life.
Over this extended period, which can span decades, the system will be subject to various
modifications—either to add new functionality or to fix problems—and go through technology
updates to the underlying hardware, operating system, network, and so on. The system will also
require continual housekeeping support with such activities as data backup. When we talk about
life-cycle models, we're therefore talking about something that's a bit wider than the models that
you'll find in a context that's pure development.
Experience with previous systems gives some rough guidelines to the sort of cost profile that you
might expect. Most medium to large organizations spend around 25 percent of their IT budgets
on new systems and 75 percent on maintaining existing systems. Typically, you could expect the
cost of development to represent about one third of the total cost of ownership for a system that's
in service over a reasonable period of time. This takes into account some skew in the figures
caused by systems that aren't successful and end up either getting canceled before
commissioning or being withdrawn after only a short period.
E-commerce systems haven't been around long enough for us to know what their typical life
cycle would look like, although there are some early indications. Time frames appear to be more
compressed, with systems being discarded and replaced after a relatively short operational life
but with correspondingly accelerated development times. Overall, though, it looks as though the
2:1 ratio of operational to development costs is likely to remain a reasonable guideline for the
near future.
Within the lifetime of a system, bursts of activity tend to be interleaved with periods of
comparative calm. Obviously, activity is at its most intense while the system is being created, but
the lesser peaks during what is theoretically maintenance of the system will eventually add up to
more. Given the dominance of nondevelopment costs, it's obvious good sense to make sure that
we do everything possible to minimize them.
Managing evolution
Coping with changes
It's possible to feel positive or negative about the need for change. If we successfully react to a
new business opportunity, we can feel good that our organization is moving forward into a more
competitive position. On the other hand, a lot of change is associated with the need to correct a
problem, and it can seem that we're running fast but getting nowhere. One thing's for sure:
Change is normal. The world will evolve, and our information systems will have to evolve with
it. Unfortunately, the way that most IT development projects are organized encourages denial.
Defining and producing an information system is frequently set up as a one-shot exercise, with
the need to be reactive seen as Somebody Else's Problem. Taking a broader view, though, the
inevitability of change means that any truly useful approach must accommodate change in an
organized way, and this has to apply to business rules and business models.
Tracking changes
Let's start with the most basic requirement of all. You can't control something if you can't
identify it. You need to be able to look at two versions of the same thing and say, "Aha, they're
different!" Because the things we're dealing with are somewhat abstract, you will need labeling
to indicate that a change has taken place.
This labeling usually comes as a version number: a value that increases in a predictable way
with each successive change. Actually, labeling doesn't need to be purely numeric; anything that
has a defined order can be used, such as the letters of the alphabet. It's quite common to use a
multipart version number, with each part giving a rough indication of the significance of the
change; so a change from version 1.1 to version 2.0 might be a major change, whereas going
from version 1.1 to version 1.2 would be a minor change. Schemes using two-, three-, or even
four-part version numbers abound but not consistent rules about when to update which part,
especially at the least significant end of the number. All you can do is demand that at least some
part of the version number change monotonically—always increasing—so that you can
immediately see which version is the latest.
You will need to decide a couple of things in relation to models and rules. The first is the
granularity of control you want. If we assume a hierarchical relationship for rules, whereby a rule
can appear in one or more rule sets, and a rule set can appear in one or more models, the main
choices are
1. Control by rule. (Updating a rule updates the version number of the rule, its rule sets, and
its models.)
2. Control by rule set. (Updating a rule updates the version number of its rule sets and its
models.)
3. Control by model. (Updating a rule updates the version number of its model.)
A small grain size—by rule, in this case—means that you have more things to control, but
changes can be accurately located. A large grain size—by model, in this case—gives you fewer
things to control but less precision about what has changed. Extending this approach to models in
general brings in more complications, in the form of processes, objects, events, and so on. You've
heard it before, but there's no standard answer: It's your call.
The other thing to mull over is whether you need a change history. In some cases, it's enough just
to note that A is not compatible with B. In other cases, you may need to know that A used to
work with B. If so, you will need to create a historical trail of which change happened when.
Similar comments apply to recording who is responsible for each change. You may be happy just
to know who fouled up last time, not the whole dynasty.
Maintaining consistency
Of course, simply being able to identify changes is not of much use on its own. We can't even be
sure that we've chosen the right level of granularity until we appreciate the real goal: being
confident that we can identify a consistent set of independent entities. We need to worry about
two main kinds of consistency:
 Getting the right set of peer components that fit together to make up an assembly that we
want to treat as a single unit
 Preserving the correspondence between intrinsically different kinds of things that
nonetheless have an important relationship
An example of the first type is a software module that's built from several source files. When
building the module, we need to be sure that we're using the right version of each of the source
files. An example of the second type might be the relationship between the same software
module and a business model. Which version of the module goes with which version of the
model?
Something to be aware of here is the need to differentiate between versions and variants. A new
version replaces the previous version. The replacement may not happen immediately: If you've
got some oldies around, it may not be convenient to slot a newcomer into their place right away.
It might even be reasonable to skip an update and wait for a later version. But any new usage
should take on the latest version, not try to pick up something that's known to be out of date.
In contrast, a variant is an alternative to what exists. It's a different flavor of something that's
already familiar. A variant might arise because of the need to provide the same functionality in a
different environment or a slightly different range of functionality in the same environment.
Either way, it's not a replacement, and a new variant will exist happily alongside other existing
variants.
The essential difference is summarized in Figure 8-1. The diagram shows a time sequence from
left to right. We start with thing A at an initial version: 1.0 in this case. Then stuff happens.
There's a request to improve the performance of A in some situations. We can do it, but it will
make A more expensive. To avoid loading the cost increase onto all the users of A who don't need
it all, we make a variant, B, along with a small change to A. We now have a new version of A,
along with a new variant, B, both of which can lead independent lives. Later, we need another
variant of A, so a new branch, C, starts up. At the point in time corresponding to the right-hand
end of the diagram, we can pick from variants A (at version 2.0), B (at version 1.2), or C (at
version 1.0), depending on the situation.
This may all seem pedantic and picky, but just ask anyone who's had to grapple with "DLL hell"
in Windows about the practical implications. Releases of Windows prior to Windows 2000 made
the innocent assumption that a DLL (dynamic link library) could be replaced by a later version
without breaking any program's dependence on the earlier version. Like all fairy stories, this is a
charming idea but, regrettably, not a good match to the real world. More recent releases of
Windows have had to allow for "sideby-side versioning," which is another term for what we're
calling variants.
This is something that more mature industries, like manufacturing, understand and work with as
a matter of course. With so much hype and so many conflicting agendas in IT, simple truths get
buried under this year's new language, this month's conference, or this week's press release. It's
really not too difficult to create a manifest for any assembly that details the set of compatible
configuration items that go together. In fact, the emerging Microsoft .NET framework takes
exactly this approach. The unit of deployment is an assembly, which contains one or more
modules. Exactly one module in an assembly contains a manifest, detailing the full contents of
the assembly.
You won't be able to solve all the problems of the IT industry. But you can make your own life a
lot easier by observing some straightforward principles.
 Make a conscious decision about what you consider to be a configuration item.

 Have a watertight method for tracking changes to those items.
 Make configuration information part of any deliverable.
Managing multiple models

For simplicity, most of the earlier discussion in this book talked in terms of a single model. In
reality, you will have to cope with multiple models that need to coexist. For several reasons, you
will end up with more than one model, and each will have to be a configuration item in its own
right.
 Models may be limited in extent for reasons of practicality or to meet the aims of a
particular project. The most common boundaries are defined by the extents of
organizational units or geographical locations or both. Over time, models covering
several extents of the same sort may be produced, and these will need to be consistent.
For example, you might start with a model of the eastern region of the organization and
then progress to the central and western regions later.
 Models may be produced to cover different viewpoints on the same area. Especially
common in this context is the use of separate models to cover analysis—a logical view of
an information system—and design—an implementation-oriented view of the same
system. Obviously, these will need to be kept in step, and we'll look at some ideas shortly.
 Models may relate to different points in time. The most obvious examples are models of
the situation as it exists at present and as it's intended to be in the future. You may have
more than one future model: For instance, there may be a corporate 3-year planning
horizon, and you may be required to maintain a model of how things might be in that sort
of time frame.
The current state of the art offers little in the way of tool support for coordinating various models
of this kind. Some kind of process will be required to keep your models in step. Taking a more
specific example, Figure 8-2 shows two ways of coping with the need for both analysis and
design models. In both cases, we'll assume that the first steps are going to be an initial version of
an analysis model, which becomes the basis for the first version of a design model. If things
could end there, life would be great. Life being what it is, though, both models will need to
evolve.
The sequential approach tries to achieve consistency through alternating handover of the same
model from analysis to design and back. Another spin on this is to treat both analysis and design
aspects as different areas of the same model. Only one group—analysts or designers—is
permitted to edit the model at one time. This helps to prevent analysis and design from getting
out of step but only at the price of slowing the work down. Designers have to wait for the
analysts to finish their latest round of changes before they can get on, and vice versa. There's also
the danger that one group will change a feature introduced by the other group, which then gets
reinstated by the first group, and so on.
The parallel approach is probably a more realistic alternative. Now, both teams can progress their
respective models at their own pace but at the risk of introducing incompatibilities between the
two viewpoints. To check for these, and to decide how to handle modifications proposed by the
other team, it will be necessary to set up joint review meetings at appropriate points. These
sessions are costly in time and energy and require careful management. The big danger is that an
us-versus-them mindset will build up, with each group effectively ignoring the input of the other,
so each ends up going its own way.
There's no perfect answer to managing multiple models. But if you at least recognize the
potential problems, you can start to think about possible solutions.
Deploying rules
Testing a new system
Once the rules have been incorporated into a deliverable unit, though, we can do proper testing.
Testing can happen at several levels. Unless you're building something tiny, you will have at
least three levels of testing.
 Unit testing, the lowest of these levels, is where the realizations of the rules meet up with
other bits of the machinery in a state to do some real work. It's up to you to define what
you mean by a unit: In Windows, for example, it might be a COM component
encapsulated in a DLL. Before you do anything else with a unit, you'll want to get some
confidence that it appears to do what it should. This requires a test harness to cover for
the other parts of the system that aren't there yet and a supply of suitable test data.
 The next step up is integration testing. Here, you're progressively adding together the
already tested units to make larger and larger chunks of the final system. In the context of
a particular system, it should be obvious which units go together to make meaningful
chunks. As the functionality included gets more complete, it should be possible to use test
data with a closer resemblance to the kind of thing that will be encountered in practice.
 The final level is acceptance testing, so called because it's usually an essential step in the
system's being accepted as fit for the business owner's purpose. By this stage, all the units
will have been integrated to form a fully working system. Now the test data can look
exactly like the real thing, and real users can try the system out, possibly for the first
time. It may also be the first opportunity to try out some of the nonfunctional aspects,
such as response time.
These levels also form the rough chronological sequence in which tests are applied. It may be
possible to overlap unit testing and integration testing to some extent if early modules from the
unit test can be integrated while others are being completed. Acceptance testing, though, has to
wait until all the integration and integration testing have been completed, so it definitely comes
last. Depending on your local situation, you might need to modify this scheme somewhat to
introduce additional levels or to make a partial delivery of something less than the full system.
Although business rules are unlikely to be exposed directly at any of these levels, they can
provide a very valuable input to the testers and help them to define the test cases that should be
applied. For example, a unit might incorporate a rule that says something like:
The tester might decide to test the unit, using age values of –1, 0, 17, 18, 19, and 999, with the
values 17 to 19 being used because of the existence of the rule and the other values chosen
because they represent interesting boundary conditions. These same values may also need to be
included in subsequent tests at other levels to make sure that something else hasn't hexed a
previously good unit.
At the level of acceptance testing, other parts of the business model can also be used to define
what to look for. In particular, it should be possible to run through all the business narratives to
show that they all behave as would be expected, especially in the way that they cope with
alternative scenarios.
All the materials—test specifications, test harnesses, test data, and test results—should be treated
as configuration items in their own right. It should be possible for you to identify exactly what
tests have been carried out and to be able to repeat any of the tests, if necessary, in the future.
Rollout
Prior to rollout, you can do a few things to reduce the risks that always accompany new systems.
If this is your first attempt at a system relying heavily on business rules, you might consider
introducing a proof-of-concept (POC) milestone into your project plan. This should provide
assurance that you can manage the technology and gives an early opportunity to check out such
features as the ability to scale under load before investing too much effort.
One final point to bear in mind when planning the system rollout is the need for fallback policies
to deal with problems encountered. These policies are not intended to cover the same ground as
any business continuity mechanisms that will be in place to support normal operations. The
fallback measures will be required for only a short period and will be removed once the system
enters live operation. There's no reason why a rule-centered system should be particularly
vulnerable to problems during rollout, but anything incorporating new and comparatively
unknown technology could have some unexpected side effects, which, of course, are bound to
become apparent at the most awkward possible time.
Chapter 5
Business Rules and Models Continuation
Topics
 Tools to support rule management

 Tools Repository
 Repositories and rules engines
Tools to support rule management

Here are the most important things you should have in your toolkit in relation to business rules:
1. Modeling tool. Business rules are rooted in business models, so you're going to need an
efficient way of modeling your requirements. Some level of UML compatibility is
essential, but don't expect UML alone to be the answer. Separation of structure from
presentation; the ability to import and to export a range of formats, including XML; and
automation capabilities are much more important than are colored icons.
2. Rule definer. You can produce perfectly good rule statements by using nothing more
than a simple text editor, but it can become hard work, and it's easy for errors to creep in.
A better option is a tool that's specialized for defining rules. In earlier chapters, we saw
some of the basic principles that could be used: controlling rule structures through
templates, enforcing references to the fact model, and so on.
3. Logic simulator. It's virtually impossible to check even a moderately complex rule set by
eye. We looked at a typical scenario in other chapter and saw how using even a simple
spreadsheet could reveal unsuspected features lurking in our rules. Little is available on
the market in this specialized area, so you may decide to use something that you already
have lying around, even though it's not perfect.
4. Repository. In a large organization, rule populations can run into the thousands, and
controlling them with a paper system alone would be well-nigh impossible. A good
repository is probably the key tool in rule management. It will contain not only the
definitions of every rule but also a number of cross-references and other supporting
information.
5. Other management tools. Most of the other tools you'll need will probably already be
around because they're a feature of most IT shops. On the development side, these tools
include a decent configuration-management tool, or version-control system. On the
operations side, such tools as alert detection and log analysis should already be in place.
Overall, having a well-equipped toolkit comprising these essential components is critical for
effectively managing and implementing business rules within an organization, ensuring
consistency, accuracy, and compliance with business requirements.
Business rules management

Business Rule Management (BRM) refers to the process of capturing, storing, organizing, and
managing business rules within an organization. It involves defining, maintaining, and enforcing
the rules that govern how business processes are executed and decisions are made. BRM aims to
ensure consistency, accuracy, and compliance with business policies, regulations, and objectives
across the organization.
Key components of business rule management include:
1. Rule Definition: This involves identifying and documenting the specific rules that govern
various aspects of business operations, such as pricing, eligibility criteria, approval processes,
and compliance requirements. Rules are typically expressed in a clear and unambiguous format
that can be easily understood and implemented.
2. Rule Repository: A centralized repository or knowledge base is used to store and organize the
business rules. This repository serves as a single source of truth for all rules within the
organization, making it easy to access, update, and reference them as needed.
3. Rule Authoring: Business rule authors, often subject matter experts or business analysts, are
responsible for creating and maintaining the rules. Authoring tools and platforms may be used to
facilitate this process, providing features such as rule templates, validation checks, and version
control.
4. Rule Validation and Testing: Before being deployed into production, business rules undergo
validation and testing to ensure they function as intended and achieve the desired outcomes. This
may involve unit testing, integration testing, and validation against real-world scenarios and data.
5. Rule Execution: Once validated, the business rules are deployed into the organization's
systems and processes for execution. Rule engines or rule execution environments are used to
automate the evaluation and enforcement of rules in real-time as part of business operations.
6. Rule Monitoring and Maintenance: Business rules are continuously monitored to ensure they
remain effective and aligned with evolving business requirements, regulations, and market
conditions. Regular maintenance and updates may be required to address changes in rules or
underlying business processes.
7. Rule Governance: Rule governance processes and policies are established to manage the
lifecycle of business rules, including rule creation, review, approval, deployment, and retirement.
Governance helps ensure that rules are managed in a systematic and controlled manner, with
appropriate oversight and accountability.
Overall, business rule management plays a critical role in enabling organizations to implement
and enforce consistent, transparent, and agile decision-making processes across the enterprise.
By effectively managing business rules, organizations can improve operational efficiency, reduce
risk, enhance compliance, and drive business innovation and agility.
Nature of business rules within the organization

1. Decision Management: Business rules are often a fundamental component of decision
management systems. Decision management involves automating and improving decision-
making processes within an organization by leveraging business rules, analytics, and other
technologies. It aims to make decisions more consistent, transparent, and efficient.
2. Business Rules Engines (BRE): Business rules engines are software tools or platforms
designed to execute and manage business rules efficiently. These engines provide features such
as rule execution, inference, versioning, and monitoring. They are often integrated into larger
business process management (BPM) or decision management systems.
3. Rule Interchange Formats: To facilitate interoperability between different rule management

systems, various rule interchange formats have been developed. These formats allow rules to be
expressed in a standardized way, making it easier to exchange rules between different systems.
Examples include the Decision Model and Notation (DMN) standard and the Rule Interchange
Format (RIF).
4. Rule Mining: Rule mining is the process of automatically discovering business rules from data
or existing systems. This technique is particularly useful when dealing with legacy systems or
complex datasets where manual rule extraction is impractical. Rule mining algorithms analyze
data patterns and correlations to infer implicit rules.
5. Regulatory Compliance: Business rules play a crucial role in ensuring regulatory compliance
within organizations. Industries such as finance, healthcare, and telecommunications are subject
to numerous regulations and standards. Business rules are used to codify these regulations into
automated decision-making processes, helping organizations remain compliant while minimizing

the risk of non-compliance penalties.
6. Continuous Improvement: Business rules should not be seen as static entities. They often need
to be updated or refined based on changing business requirements, regulations, or market
conditions. Continuous improvement practices, such as rule testing, monitoring, and
optimization, help ensure that business rules remain effective and aligned with organizational
goals.
7. Domain-Specific Rule Languages: In some cases, specialized rule languages are developed to
express domain-specific rules more effectively. For example, the Drools rule engine provides a
domain-specific language (DSL) for expressing rules in the context of business processes and
workflows.
8. Natural Language Processing (NLP): With advancements in natural language processing

(NLP) technology, there's growing interest in techniques for automatically extracting and
interpreting business rules from unstructured text sources such as contracts, legal documents, and
policy manuals. NLP can help streamline the rule discovery process and ensure that no important
rules are overlooked.
Examples of business rules
Let's create a simple example to illustrate both business rules and a business model.
Example: Online Retail Store
Business Rules:
1. Order Processing Rule: If a customer places an order on the online retail store's website, then
the order must be processed within 24 hours.
2. Inventory Rule: If a product is out of stock, then it cannot be added to the customer's shopping
cart.
3. Shipping Rule: If the order total is above $50, then shipping is free; otherwise, standard
shipping fees apply.
4. Return Policy Rule: If a customer returns a product within 30 days of purchase and it's in its
original condition, then a full refund will be issued.
5. Promotion Rule: If a customer enters a valid discount code during checkout, then the discount
will be applied to the order subtotal.
Creating Business Rules
1. Identify Requirements: Understand the needs and goals of the online retail store, such as
ensuring timely order processing, managing inventory effectively, providing a positive customer
experience, and maximizing sales through promotions.
2. Analyze Processes: Review existing processes and workflows to identify where rules are
needed to govern decision-making and operations. For example, consider the steps involved in
order processing, inventory management, shipping, returns, and promotions.
3. Define Rule Logic: For each aspect of the business, define the specific conditions and actions
that constitute a rule. Use clear and unambiguous language to express the rules in a format that
can be easily understood and implemented.
4. Document Rules: Document the business rules in a structured format, such as a rule repository
or knowledge base, to ensure they are accessible to relevant stakeholders and can be easily
referenced and updated as needed.
5. Test and Validate: Test the business rules to ensure they function as intended and achieve the
desired outcomes. Identify any potential conflicts or inconsistencies between rules and address
them accordingly.
6. Implement and Monitor: Implement the business rules within the online retail store's systems
and processes. Continuously monitor and evaluate the effectiveness of the rules, making
adjustments as necessary to adapt to changing business requirements and market conditions.
By creating and implementing these business rules, the online retail store can ensure consistency,
efficiency, and compliance with its operational objectives and customer expectations. These rules
serve as the guiding principles that govern how the business operates and interacts with its
customers.
Consider another example in the context of a subscription-based streaming service like Netflix.
Example: Subscription-Based Streaming Service
Business Rules:
1. User Registration Rule: If a user wants to access the streaming service, they must register for
an account using a valid email address and create a password.
2. Subscription Plan Rule: If a user wants to access premium content, they must subscribe to a
paid plan. Free trial subscriptions are available for new users for a limited period.
3. Content Availability Rule: If a user searches for a specific movie or TV show, only content
available in their subscription plan or region should be displayed.
4. Streaming Quality Rule: If a user's internet connection speed is below a certain threshold, the
streaming quality should automatically adjust to ensure smooth playback.
5. User Profile Rule: If a user watches specific genres or types of content, personalized
recommendations should be provided based on their viewing history.
6. Payment Rule: If a user's subscription payment fails, they should receive a notification and be
prompted to update their payment information to avoid service interruption.
7. Content Licensing Rule: If a license for a particular title expires, it should be removed from
the streaming service's catalog until a new license is obtained.
Creating Business Rules:
1. Identify Business Objectives: Understand the goals of the streaming service, such as attracting
and retaining subscribers, providing a seamless user experience, and complying with content
licensing agreements.
2. Analyze User Interactions: Analyze the different touchpoints and interactions users have with
the streaming service, including account registration, content browsing, playback, and billing.
3. Define Rule Conditions and Actions: For each aspect of the service, define the conditions that
trigger specific actions or decisions. For example, determine the criteria for recommending
content, adjusting streaming quality, or handling payment failures.
4. Document Rules: Document the business rules in a centralized repository or knowledge base,
ensuring they are accessible to relevant stakeholders, including product managers, developers,
and customer support teams.
5. Test and Validate: Test the business rules in a controlled environment to verify they function as
intended and achieve the desired outcomes. Address any issues or inconsistencies identified
during testing.
6. Implement and Monitor: Implement the business rules within the streaming service's software
systems and processes. Continuously monitor user interactions and system performance to
identify opportunities for optimization and refinement of the rules.
By implementing these business rules, the streaming service can deliver a tailored and reliable
experience to its subscribers while efficiently managing content availability, user preferences,
and payment processing. These rules serve as the backbone of the service's operations, guiding
decision-making and ensuring consistency and compliance with business objectives.
If you've adopted a particular rules engine, it may bundle in some tools, and these are the ones
you'll probably end up using, however far from ideal they may be. When you're evaluating rules
engines, don't forget to include the management tools as part of the assessment.
Most organizations will always prefer to buy a product to do a job rather than go to all the
trouble and effort of building one themselves. This is usually the right decision because of one
simple factor: support. It can sometimes seem strange that you need to go outside to get support
for something that's crucial to your organization, but it reflects the economies of scale.
Taking a cold-blooded mathematical view of the world, it's obvious. If the cost of supporting a
tool is x, then:
Support cost for home-brew tool = x * 100%

Support cost for purchased tool = x * i/n * 100%
where i is an inefficiency factor, taking into account that the vendor needs to make a profit, and n
is the number of customers supported. For an in-house tool, i = 1, and n = 1, so they cancel out.
For a purchased tool, i is generally much smaller than n, so it's clear that the economics are likely
to be better. There's also a simpler existence proof. If doing it inhouse were really cheaper, there
wouldn't be any products around. The one area that might be an exception is a rule repository.
This is so important that it deserves a separate section.
Repositories and Rule Engines

If you have a rules engine, it will already provide at least some of the features just listed, so it's
reasonable to ask whether you need a rule repository in addition or whether the rules engine
alone is sufficient. The answer hangs on what your rules engine does about external rules: rules
that it doesn't implement but that nevertheless exist elsewhere in the system. Most rules engines
ignore the existence of any other kind of business logic. Unfortunately, you can't afford to do
this.
A rule repository is a centralized storage system or database where organizations store and
manage their business rules. It serves as a single source of truth for all the rules within an
organization, providing a structured and organized environment for storing, accessing, and
managing rules throughout their lifecycle.
However wonderful your rules engine, it's not realistic to put absolutely everything in it. The fact
that the do-everything expert systems of the 1980s and 1990s are no longer around in their
original form is a testament to the failure of this line of thinking. The plain fact is that you're
bound to have some rules for which your only alternative is to locate them outside the rules
engine: in a fat client, in a database, in a legacy system, in a workflow tool, or in a number of
other places.
You can take the attitude that only the rules in the rules engine are proper rules, that all the others
can be ignored. But this would be a big mistake. You will lose the ability to check your business
logic properly, because chunks of it will be missing. You will not be able to have a rational
discussion about whether a rule should be implemented inside the rules engine or outside, if logic
outside the rules engine is deemed not to exist. You may be forced into a tortuous realization of a
rule or rule set within the rules engine that could have been done in a simpler way outside, just to
get some management control.
The other possibility is for a rules engine to introduce a little distance between the definition of a
rule and its implementation. In principle, this would allow the rules engine to act as the central
control point for all rules and the implementation route for some. For rules not implemented
internally, the rules engine could provide a place for the user to add information about how the
rule had been realized, along with a modicum of additional housekeeping information.
Unfortunately, most current products lean toward the closed-world assumption and aren't very
adaptable.
It's more fruitful to think about this in a different way. You would like to have a rule repository
that covers all the angles we described, without being boxed in by what a rules engine allows. So
treat yourself and have one! It's not as scary as it sounds, and we'll look at the practicalities
shortly. Figure below shows the kind of configuration we want to achieve.
Rule definition refers to the process of identifying, articulating, and documenting the specific
rules that govern various aspects of business operations. During this phase, organizations
establish the guidelines, conditions, and actions that determine how decisions are made and
processes are executed within the business.
Rule realization refers to the implementation and execution of the defined rules within the
business processes and software systems of an organization. It involves translating the abstract
rules into executable logic that can be applied to real-world scenarios and decision-making
scenarios.
But what to do if you also have a rules engine? Won't they conflict? Not if you manage things
correctly. The key point to remember is that most rules engines try to combine rule definition and
rule realization. You can treat your rules engine as a kind of container that implements rules in a
particular way: a superduper container, for sure, much better than a lump of C++ or Java but
ultimately just something that contains some rules. Figure below shows the concept.
A rule engine is a software component or system that evaluates and executes business rules
within an application or system. It provides a framework for defining, organizing, and applying
rules to make decisions and automate processes based on specific conditions or criteria. Rule
engines are commonly used in various industries and domains, including finance, healthcare,
manufacturing, and telecommunications.
This is not belittling the rules engine; it's enhancing it. You can still use all its facilities, and
you'll probably find it a more comfortable way to implement your rules than most alternatives.
But you have to make it a member of your family of realizations.
The head of the family is the rule repository, which knows who's related to whom and knows
about all the tribal relationships. But not everyone lives with the head of the family; in fact, most
members of the family are out living their own lives in their local communities. The wise old
repository understands this fact but still keeps lists of addresses and birthdays and a whole load
of other things that bind the family members together.
What if you don't have a rules engine? It's not a problem. Contrary to what some vendors will tell
you, rules can and do exist without their products. You can think of the repository as a "virtual
rules engine," with the implementation aspects federated out to a number of separate resource
providers. You can choose the providers and the way that they realize the rules, and you can
make a different choice whenever you want to.
Chapter 6.
XML and Application Integration
Topic Outcomes
1. Understand Basic PHP sytax and web XML configuration using CRUD.
2. Analyze how data will transfer in different modules of the system.

3. Create and conceptualize basic to advance user-friendly User Interfaces.
4. Understand how websites create access into the domain and to its server.
5. Understand the value of XML in different software integration process.
6. Use XML to perform decision support in different software applications.
XML, XSLT, and Application Integration

XML is clearly a component of application integration and not a replacement, as once thought.
XML's value is that it promotes a self-defining message structure that most organizations can
agree upon, and many application integration architects are using it as a standard format for
information exchange.
However, the real value of XML may not be XML itself, but XML derivatives such as
ebXML, SOAP, and XML. These standards are still evolving, but they already add value in
application integration problem domains.
In this chapter we'll explore the strategic value of XML as well as its transformation
standard, XSLT, and their use in the world of application integration. This is a jumping-off point
for the following chapters that will explore the ins and outs of XML-related standards.
Since its inception, Extensible Markup Language (XML) was designed as a standard for
information interchange on the Internet; thus, its natural application in the world of application
integration. Those interested in application integration look to leverage the power of XML,
making this new standard a common point of integration for source and target applications.
So, What's the Big Deal?
The strengths of XML make it extremely valuable in all types of application integration projects.
Still, its real value resides in the world of application integration as the infrastructure for
information exchange and management.
XML provides a robust, human-readable information-exchange standard that is not just a

consensus choice, but a unanimous one. It can support the exchange of application semantics and
information content, providing an application-level mechanism for producing business

information that other applications can use without needing to understand anything about the
transmitting applications (see Figure 11.1).
XML gets most of its "traction" from this common mechanism for information exchange. More
specifically, it gets its traction primarily around two application integration problem domains:
intra- and intercompany.
Fundamentally, intracompany application integration is about binding applications and data

stores together to solve business problems. Its strength is facilitating the free flow of information
from any system to any other system, with each of those systems gaining access to perfect
external information in real time. Intracompany typically integrates ERP packages such as SAP,
PeopleSoft, and Baan, in addition to Customer Relationship Management (CRM) packages,
databases, and older mainframe systems. Intracompany application integration also allows
organizations to externalize existing enterprise application information to interested parties
through the Web, as evidenced in a portal-based solution.
Knowing, as we now do, that the essence of application integration is the binding of applications
and data stores together in order to share information with external and internal information
systems, we can see that intra- and intercompany application integration are intrinsically related.
Application integration constructs the infrastructure that supports the free flow of information
between companies. As such, it is functionally an extension of the intracompany infrastructure
that includes enterprise applications existing in other organizations.
The design patterns of applications and data stores in the application integration problem domain
are similar to those in intracompany application integration problem domains. All that changes is
the mechanisms employed to exchange the information, which in an application integration
environment are generally less intrusive and more data oriented than in the intracompany
application integration environment.
The Value of XML

XML provides a common data-exchange format, encapsulating both data and metadata. This
format allows various applications and databases to exchange information without having to
understand anything about one other. In order to communicate, a source system simply reformats
a message, a piece of information moving from an interface, or a data record as XML-compliant
text and moves that information to any other system that understands how to read XML.
Although we can now appreciate XML's value to application integration, it was originally
created as a mechanism to publish data through the Web without the originator having to
understand anything about the system sending the data. As the application integration problem
became more evident, application integration architects and developers recognized the value of
applying XML to the problem domain in order to move information between enterprises. The
success of XML has led many people to refer to it as the next EDI.
Although XML's benefits sometimes appear revolutionary in scope, as a concept it falls short of
being revolutionary. It also falls short of being the panacea for the application solution. We're not
suggesting that it does not bring some real value to the application integration solution set. That
value simply requires stretching XML far beyond its original intent which leads to a problem.
Stretched too far, XML may be applied in areas where it stands little chance of success.
The overapplication of XML in so many areas of technology diminish its real value and results in
a great deal of unnecessary confusion. Perhaps most damaging is the predictable behavior of
many vendors that look to recast XML using their own set of proprietary extensions. Although
some want to add value to XML, others seek only to lock in users.
XML's power resides in its simplicity. It can take large chunks of information and consolidate
them into an XML document meaningful pieces that provide structure and organization to the
information (see Figure 11.2).
The basic building block of an XML document is the element, defined by tags. An element has
both a beginning and an ending tag. All elements in an XML document are contained in an
outermost element known as the root element. XML can also support nested elements, or
elements within elements. This ability allows XML to support hierarchical structures. Element
names describe the content of the element, and the structure describes the relationship between
the elements.
An XML document is considered to be "well-formed" (that is, able to be read and understood by
an XML parser) if its format complies with the XML specification, if it is properly marked up,
and if elements are properly nested. XML also supports the ability to define attributes for
elements and describe characteristics of the elements in the beginning tag of an element.
For example, XML documents can be very simple, such as the following:
<?xml version="1.0" standalone="yes"?> <conversation> <greeting>Hello, world!</greeting>

<response>Stop the planet, I want to get off!</response> </conversation>
The Document Type Definition (DTD) determines the structure and elements of an XML
document. When a parser receives a document using a DTD, it verifies that the document is in
the proper format.
Some XML documents may be DTD specified, contain an internal subset, and possess a more
complex structure, such as the following:
<?xml version="1.0" standalone="no" encoding="UTF-8"?> !DOCTYPE titlepage SYSTEM

"http://www.frisket.org/dtds/typo.dtd" [<!ENTITY % active.links "INCLUDE">]> <titlepage>
<white-space type="vertical" amount="36"/> <title font="Baskerville" size="24/30"
alignment="centered">Hello, world!</title> <white-space type="vertical" amount="12"/> <! In
some copies the following decoration is hand-colored, presumably by the author > <image
location="http://www.foo.bar/fleuron.eps" type="URL" alignment="centered"/> <white-space
type="vertical" amount="24"/> <author font="Baskerville" size="18/22" style="italic">Munde
Salutem</author> <titlepage>[1]
XML parsers read XML documents and extract the data for access by another program. Parsers
are becoming part of the middleware layer (defined later), able to process XML documents into
and out of the middleware infrastructure (see Figure 11.3).
XML metadata can be any attribute assignable to a piece of data; anything from concrete
attributes to such abstract concepts as the industry associated with a particular document. XML
can also be used to encode any number of existing metadata standards. The binding of data and
metadata is a fundamental feature that maximizes XML's benefit to information-sharing
scenarios. In fact, it is the feature most consistent with the concept of a common enterprise
metadata repository that is supported throughout an organization or a common metadata layer
shared within a trading community. Currently, XML is attempting to establish common metadata
standards throughout the Internet in support of B2B, and within the enterprise in support of
intracompany application integration.
XML provides individual industries with the ability to define common metadata within their
domain. For example, the pharmaceutical industry defines the structure of product data quite
differently from the automobile industry. As a result, its metadata definitions must be different as
well. XML provides mechanisms such as namespaces (see the description in the "XML
Namespaces" tidbit later in this chapter), XML-Schemas, and RDF for defining localized
metadata around particular industries, or even between two or more trading partners. These
metadata standards are just now emerging and have yet to find wide acceptance within trading
communities.
Because XML is independent of any particular type of metadata format, there is little risk that a
particular technology vendor will define its own set of metadata tags. In other words, XML
cannot be made proprietary to any particular type of data. At least, that's the hope.
What XML Adds

Ironically, XML's real power is not in the technology itself but the fact that everyone seems to
agree that XML provides an acceptable common format to allow applications within or between
enterprises to exchange critical business information. XML is a momentum technology: Almost
everyone concerned with storing or moving information such as database and middleware
vendors hypes their products with claims of XML support. (Not surprisingly, they support XML
in very different ways.)
XML also adds a foundation that other standards can build upon. As we'll explore later in this
chapter, XML-enabled standards now exist for transforming information between applications.
These standards include Extensible Stylesheet Language Transformation (XSLT, covered later in
this chapter), BizTalk, XML for EDI (XEDI), and Commerce XML (cXML). They use XML as
their base and expand in a specific direction to address a particular business issue.
What XML Does Not Add

The hype around XML threatens to turn us all into wide-eyed kids at a carnival, ready to eat too
much cotton candy and get drawn in to every attraction. We need to step back, take a deep
breath, and consider not only what XML does, but what XML does not do. XML is no exception
to the pitfalls of other momentum technologies, in which end users tend to overestimate the
capabilities of the technology and thus incorrectly apply them within their problem domain.
One common and dangerous misconception about XML is that it is a substitute for application
integration technology such as middleware (including application servers and integration
servers). Nothing could be further from the truth! In fact, the opposite is true.
As we already stated, XML is a simple, text-based document format that provides both metadata
and information content. Nothing more. Nothing less. You or your vendor must provide the
technology to move the XML documents from application to application. You or your vendor
must make any necessary changes to your source and target applications so they can consume
and produce XML. In other words, a lot has to occur before you can apply XML to application
integration.
In order for applications using XML to be integrated, the applications must externalize the
information as XML. Currently, few applications are capable of doing so. In order to be most
successful, either the existing applications must change so they produce and consume XML or,
better yet, they must leverage XML-enabled middleware technology.
XML-enabled middleware technology manages the extraction of information from the source
system (or systems) as well as the conversion of the information into XML (if required) and the
placement of the information in the target system (or systems). All this occurs automatically and
is transparent to the end user.
XML does not make a good message format for information exchange, either intra- or
intercompany. As we noted, XML is text based, and thus information that would normally exist
in a binary message as "512 KB" could easily map to an XML document 20 times that size (see
Figure 11.4).
Although XML provides a good point of integration when communicating with source or target
applications within or between enterprises, moving information using native XML demands a
huge overhead. As a result, most middleware vendors still use a binary message format, either
proprietary or open, to move XML data and metadata from one system to another.
XML Meets Middleware

We have established that XML is a simple, text-based standard and, as such, cannot provide
everything needed to integrate disparate applications. It quickly becomes clear that, in order to
provide maximum value to the application integration solution set, XML needs middleware (and,
conversely, middleware most likely needs XML).
XML's value to middleware is clear. Middleware simply "carries the load." It moves messages
that encapsulate or abstract XML and ensures that those messages are understood by any source
or target applications that need the information (see Figure 11.5). Middleware may also manage
the interfaces with the source or target applications and move information into and out of the
applications through an unobtrusive point of integration, such as a database or an API.
Because of XML's value, every middleware vendor, new and old, has declared dominance in the
XML space, applying its technology to application integration problem domains. None of us
should be surprised that there is a certain degree of "puffery" to these declarations. In truth, it is
not particularly difficult to XML-enable a product. Therefore, vendors were able to react quickly,
for a change.
XML-enabling a product is simply a matter of embedding a parser within the middleware and
teaching the product to read and write XML from and to the canonical message format. In
addition, because many of these products already have native connectors to traditional enterprise
systems and data stores (such as SAP, PeopleSoft, and DB2), they provide enterprises with the
ability to produce and consume XML without impacting the applications.
Integration Solutions
Now that we understand what XML is, what its value is, and how middleware and XML coexist,
we can turn our attention to XML-enabled solutions that include the available technology and
approaches. In doing so, let's return once again to our macro problem domains: intracompany
application integration and B2B application integration.
XML plays a lesser role within the domain of intracompany application integration, but its role is
becoming more important. This somewhat-convoluted observation is based on the fact that most
systems within an enterprise come under central control. As a result, the integration solutions run
deeper and may not benefit from converting information to XML for movement to other
applications. Typically, standard information-exchange mechanisms, such as XML, take a back
seat to native points of integration and binary messages as a simple matter of efficiency when we
consider intracompany application integration. However, as information becomes less centrally
controlled, XML will become more important.
Let us look, for example, at a situation in which an enterprise needs to exchange information
between its PeopleSoft packaged application, its older COBOL/ISAM applications running on
the mainframe, and its new data warehouse. Although there are many ways to approach this
problem, most enterprises would use some type of integration server to exchange information
between the systems in real time, using whatever native interface the source or target
applications provided. There is always the opportunity to convert the data moving between the
applications into XML. However, binary messages typically provide better efficiency, as we
noted earlier in this chapter.
Although native interfaces currently dominate application integration solutions, we are rapidly
moving to a world where most applications and databases will be XML-aware. Therefore, XML
will become a common point of integration rather than the hodgepodge of proprietary and
complex native interfaces in use today. Taking this reality into account, we recognize that XML
is becoming a more prominent player in application integration. Many packaged applications,
including PeopleSoft and SAP, are going to leverage XML as the preferred native interface to
their systems. Indeed, PeopleSoft has already defined its Open Integration Framework (OIF) and
has outlined how information will move into and out of the PeopleSoft application using XML.
SAP is not far behind.
Even as developers build interfaces to new and existing custom applications, XML is becoming
the mechanism of choice for producing and consuming information within those systems.
Moreover, most database vendors, including Oracle, Sybase, and Informix, are providing
mechanisms within their database engines to allow them to read and write XML directly from the
database.
XML provides the most value within the domain of intercompany application integration. Here
we typically integrate applications that are not under centralized control, and thus difficult to
change. As we have explained, XML provides a reasonably good format for information
exchange. Perhaps most important, the majority of businesses can agree upon XML as the way
information moves into and out of enterprises. XML standards provide additional value by
including common metadata layers that may exist between one or more trading partners, and
even standard transformation mechanisms such as XSLT.
As we look ahead, the ultimate application integration solution will be some hybrid of
intracompany application integration and B2B application integration, providing integration
within and between enterprises by using a similar, compatible infrastructure. Getting to this
"glorious future" will be accomplished in stages. Enterprises will first learn to integrate their own
applications, which entails understanding everything about the source and target systems that
they own, and then they will learn to integrate their applications with their trading partners'
applications. XML belongs in this mix, but the majority of work in getting to the solution is
associated with exploring both problem domains, understanding the requirements, and mapping
the correct technology to the solution. In reality, most organizations have just begun the journey
down this rather long and expensive road.
XML-Enabled Standards
The XML bandwagon is filling up, joined by many standards organizations. These entities are
looking to standardize the way e-Business is conducted, using the common infrastructure they
define and vendors provide.
The sad reality is that this bandwagon is overflowing there are more XML standards
organizations than vendors and end users require. Fallout is bound to occur as one or two
standards get traction and others do not. The few that appear to be most relevant in the world of
XML and application integration include RosettaNet, XEDI, BizTalk, Extensible Financial
Reporting Markup Language (XFRML), XML-Schema, XML Query, and XSLT.
RosettaNet is a consortium of product vendors and end users that defines a framework for data
and process interchange with e-Business. Primarily organized for the high-tech industry,
RosettaNet outlines standard message data using XML, as well as standardized process flows, to
react to standard business events. We feel RosettaNet is so important that we've dedicated a
chapter to it (see Chapter 14).
XEDI is a published specification describing how to map traditional EDI to XML and back
again.
BizTalk is an industry consortium founded by Microsoft to define a standard XML grammar for
XML-based messaging and metadata. Microsoft is providing a BizTalk server to support this
standard.
XFRML is a standards push led by the American Institute of Certified Public Accountants
(AICPA) to define an XML standard for reporting financial information over the Internet to other
interested parties.
XML-Schema is a working group of the W3C that looks to describe a better mechanism to
determine the structure of an XML document (see the description earlier in this chapter).
XML Query is another W3C working group looking to create a common set of operations and
language syntax for accessing persisted (stored) XML data.
XSLT seeks to provide a standard XML document-transformation mechanism using a stylesheet

as a common processing engine. XSLT is important to application integration because schema
and information content often must be altered as information flows between applications. We
will cover XSLT next.
Using XSLT for B2B Application Integration

Although a number of standards exist for information interchange and process definition,
industry standards have yet to emerge for defining common integration server and B2B
integration server services such as routing, rules processing, and transformation. In the absence
of such standards, individual vendors have created proprietary approaches to these basic
information-processing services. As a result, we are confronted with features that are not
interchangeable, require specialized training, and do not provide a common framework of
services.
Even as we begin to implement standards such as XML, ebXML, RosettaNet, and BizTalk as
mechanisms to manage information interchange, we are also looking to create standards that
support information processing within the middle ware. These standards will define services
common to most integration servers and to B2B integration servers, including rules and
transformation.
XSLT seeks to fill the need for a standard approach to both rules and transformation processing.
Like XML, XSLT is a standard written by the W3C, and it could become the preferred standard
mechanism for transforming content and application semantics as information moves from
application to application and business to business.
The power of XSLT resides in its simplicity, tight integration with XML, and the completeness
of the standard. Although it does not provide every type of out-of-the-box transformation service
currently found in most integration servers and B2B integration servers, XSLT provides the
infrastructure to create such services through an extensible and declarative programming
language. The operative word here is "currently." You can bet the farm that, as this standard
evolves, more intracompany application integration and B2B vendors will create their
transformation and rules-processing technology to reflect XSLT.
What Is XSLT?
XSLT is a language designed to transform one XML document into another, changing both its
schema and content in the process. At its most primitive, XSLT is a text-processing system that
enables the programmer to transform XML documents, or, if required, generate other standard
markup languages such as HTML (or any text, for that matter).
In previous chapters, we have discussed the need for transformation as information moves
between applications, so we will not devote our attention to it here. However, it is important to
remember that XML documents are like messages. And because each application has its own
unique set of application semantics, documents moving from application to application need to
be transformed (see Figure 11.6). Both data structure and content must be semantically correct in
order to load into the target application. If the data is not in the proper format, the update
operation is likely to fail.
In addition to transforming the schema and content of XML documents, XSLT can perform other
types of text-processing and transformation operations, which include creating text-based
standard data formats such as comma-delimited files, PDFs, or other industry-standard formats
that use text (see Figure 11.7).
Before XSLT existed, most XML developers could only process incoming XML documents by
creating custom applications that typically invoked one of two APIs: the Simple API for XML
(SAX) and the Document Object Model (DOM).
The SAX API was an event-based interface that used a mechanism through which the parser
notified the application of each piece of information in the document as it was read. In the DOM
API, the parser interrogated the document and created an object tree structure that represented
the structure of the XML document in memory. From that point, a traditional program (e.g., C++
or Java) transformed the tree.
The limitation of both approaches was the same each time you wanted to transform a new XML
document, you had to write a new program.
XSLT provides several advantages over SAX and DOM. XSLT's design is based on the fact that
most transformation programs use the same design patterns, and therefore can be automated
using a higher-level, declarative language. (Stating that the XSLT language is declarative means
that it describes the transformation behavior rather than a sequence of instructions necessary to
perform the transformation. In other words, XSLT describes the transformation, then leverages
the XSL processors to carry out the deed.) Moreover, when XSLT is used, the requirements of
transformation can be expressed as a grouping of rules that define what output should be created
when a particular pattern is encountered.
The Mechanisms
Transforming an XML document using XSLT requires two main steps. The first step consists of
a structural transformation, during which the data is transformed from the input structure to the
output structure (see Figure 11.8). This step may involve selecting data, grouping it, sorting it, or
aggregating it, depending on the needs of the transformation. For example, within an XML
document, we can change U.S. dollar values to French francs. Such a transformation would be
based on the current conversion rate, either found statically within the transformation program or
read from a remote database.
The second step consists of formatting the text so it takes on the new characteristics. In this step,
information is placed in a particular type of text structure: XML, HTML, PDF, and so on.

Advanced System Integration and Architecture Course Module

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced System Integration and Architecture Course Module

Uploaded by

Copyright:

Available Formats

ADVANCED SYSTEM

Batangas State University – The National Engineering University

Zito Red Spartans!

Course Rationale and Description............................................................................................................................4

Introduction to Enterprise Systems for Management............................................................................................5

What XML Does Not Add.......................................................................................................................................92

Course Rationale and Description

integration solutions effectively.

Intended Learning Outcomes

 Enterprise systems In Organizations

Overview of Systems Integration: challenges and drivers

Enterprise Systems in Organizations

Information Silos and Systems Integration

Enterprise Resource Planning Systems

Business Process and ERP

ERP System Components

e-Business and ERP

3. Finally, the early focus of e-Business was on communication (e-mail), collaboration

The system benefits and limitations of ERP systems are as follows:

The business benefits and limitations of ERP systems are as follows:

ERP Life Cycle

ERP Implementation Strategies

Software and Vendor Selection

• Third-party software integration

Operations and Post-Implementation

People and Organization

Business Process Reengineering

within an ERP; however, security unfortunately remains an afterthought. The seamless

Software Extensions and Trends

Implications for Management

• Non-functional requirements – These requirements pertain to behavioral properties that a

 Operational requirements – These specify the operating environment(s) in which the

The challenge in requirements-gathering is choosing the way(s) on how to collect information.

 Interviews – This is the most commonly used requirement-gathering technique. In

People at different levels of the organization have varying perspectives on the

interview questions encourage the interviewee to expand on or confirm

How to Analyze Requirements

Characteristics of a Good Requirement

o Necessary – The requirement is really needed or specifies an essential factor on the

Using Requirements Checklist

 Discover, Design and Deliver

2. Practice and facilitate innovation and learning.

Design thinking is a problem-solving and innovation framework that emphasizes a human-

Putting Yourself in Their Shoes:

Asking the Right Questions:

Designing with Heart:

Sorting Out the Clues:

Creating a Problem Statement:

Narrowing Down the Scope:

Setting the Design Direction:

Encourage a free flow of ideas without immediate evaluation or judgment. Use

Capture All Ideas:

Categorize and Prioritize:

Core Principle of Design Thinking

1. Writing is greater than talking

 Life – Cycle Costs

1. Examine the problems and alternatives in the cost production.

2. Understand software and business changes.

3. Know the components of testing new systems.

Coping with changes

 Make a conscious decision about what you consider to be a configuration item.

Managing multiple models

 Tools to support rule management

Tools to support rule management