1
Enhancement Of Enterprise
Systems Through Development
And Maintenance Projects
Development or maintenance projects are often a small part of enterprise-
wide IT systems, which contain information systems like enterprise resource
planning (ERP), supply chain management (SCM), human resources
management systems (HRMS) and a host of other homegrown and third-
party applications. Put another way, the application commissioned on a
successful completion of your project might share data and processes with
many other systems in the organization. This sharing, for example, can be
master data from an ERP or workflows from a Lotus Notes application. At the
end of a work day, your application might be uploading tons of transaction
data into a corporate data warehouse that can help the business, say by
generating analytical reports on customer profiles.
As a technical team member on the project, it will help you do your job
better if you understand the big picture—how your project fits in the overall
corporate scene. What business problem is your assignment solving in the
overall organizational context? The answer to that question may lie in the
project charter. You can also ask your project manager and other senior
team members. You might even request an informal seminar, led by project
stakeholders, that explains how the project functions within the larger
perspective. Unless the project is very sensitive or confidential, these kinds
of requests will usually be appreciated and show that you are eager to
develop a wider perspective.
In the case of ERP and SCM projects that have an effect on the functioning of
almost an entire organization, getting a big picture view is relatively easier
as the project moves on. When an ERP project goes live in production, for
example, you can easily judge how your work has affected the organization.
Pay attention to results; they can be unique and golden opportunities to
develop a business perspective. So you need to keep your eyes open—even
if you are working on a small part of a big project.
How Your Project Fits into The Big Picture
As I have just discussed, getting the big picture is very important in
understanding the business aspect of your project. Let's take a look at how
your piece of the puzzle fits into the whole.
Module or subsystems: First, understand the module, the project
you are working on. You might be using some data structures,
2
algorithms, and probably some design patterns. Maybe it's a simple
three-tier architecture having a front end, a middle tier with
application logic, and a database. Or maybe it's more complex,
involving messaging and e-mail with a service-oriented
architecture. Naturally, many more variants in terms of complexity
and architecture are possible.
Application or system level: Next, ask yourself some questions that
reveal how your module interfaces with other subsystems to form a
complete application. How are data and processes shared? How are
complex transactions getting processed across modules? How is
the navigation built in across different user interfaces? What types
of messages are displayed by the application to users when there is
an error, while in process, and on completion of transactions? Are
user interfaces intuitive enough? Do they give the same look and
feel across the application? What are the different workflows,
database operations, or even reports and dashboards that are
integrating numerous subsystems together? These are just a few of
the questions you might ask. When you answer them, you will be
doing yourself a big favor and making your job easier. In addition,
you'll get a firm grip on the business problem being addressed by
your project. And you'll get an idea of how it fits into your
organization's overall business strategy. Take some time to think
through these ideas.
Interfaces with other systems: Having mastered the application
level, now it's time to look at your application's interfaces with
other systems within and outside your organization. Your
application might be heavily dependent on an ERP like SAP for
master data on product codes, bill of materials (BOM), product
routing, cost data, and so on. In turn, your application might be
uploading transaction data like customized equipment
configuration, resource utilization, and resource calendar on a real-
time basis or as a batch job at the end of a business day. The exact
functionality of these systems is always determined by business
users or the end users, as they are called more often.
Your application might also be interfaced in a similar fashion with many
other applications that are homegrown for the organization's specific
processes or other third-party software, like accounting and content
management systems. This is a typical scenario—a newly commissioned
application shares data and workflows with other ERPs and both homegrown
and third-party applications. Large corporations often have multiple
enterprise-wide applications along with hundreds of homegrown and third-
party systems. It's not difficult to imagine the complex web of system
interfaces, interconnecting these numerous applications. Many of these
3
applications and interfaces may be critical to the business and have 99.99
percent system uptime requirements. Anything less might translate into
millions of dollars lost in revenue. Add to it the financial losses due to lost
business opportunities and customer goodwill.
Again, take some time to analyze how the application you contribute to
interfaces with the broader, enterprise-wide systems. Imagine the costs,
infrastructure, resources, and skills required for supporting this kind of IT
organization. Now you're looking at the big picture!
Understanding Enterprise IT
Developing a business perspective will naturally require a thorough
understanding of how an enterprise works. You may be in the engineering
sector, service sector, or any other sector; the basic elements will remain the
same. Broadly, you have sales and marketing to bring in customer orders;
operations to efficiently execute them; and finance, accounting, and human
resources to take care of resource management and support. You can have
further subdivisions like distribution, customer service, materials
management, production planning, research and development, shop floor
control, quality control, purchasing, administration, facilities, and so on.
These functions of an enterprise have to work in a coordinated fashion to
deliver desired goods or services to the marketplace. The better the
coordination, the more competitive the enterprise! So it's all about
coordination and the resulting operational efficiencies when that is done
well. No enterprise function can work in isolation.
Now let's turn again to IT, which is our main focus here in Part I. (In Part II, I
will talk more about business and other skills.) Just as with enterprise
functions, no serious IT application can work in isolation. An application has
to work in coordination with other systems within the organization to
produce meaningful work. Since coordination and system interfaces are so
important, why not develop an enterprise or business perspective for our IT
systems and projects? Let's examine something called “enterprise
architecture,” which can help develop that business perspective.
Enterprise architecture is not specifically an IT concept. It encompasses the
relationships between business strategy, business goals, and business
processes, as well as the applications, data, and IT infrastructure that
supports these things. It therefore includes processes, inputs, technology
infrastructure, software components, services, and personnel roles. It also
includes the associations between these parts, the guiding principles that
govern how the structure is constructed, and ultimately how that structure
delivers business value. Software components are thus only a small part of
the enterprise architecture concept. Let's examine further.
4
According to a recent IBM white paper,1 enterprise architecture has four
major components.
1. Strategy architecture: This includes business objectives, strategies,
and ways to implement them.
2. Business architecture: This includes business services and
capabilities, business locations, and organizations.
3. Information systems architecture: Systems that implement
business processes and business scenarios. It also includes data
and personnel.
4. Technology architecture: This includes hardware and software
components used to run information systems.
This visibility helps business and IT decision makers allocate funding and
implement projects that can generate the most value. Strategies, tactics,
and capabilities are all governed by business policies, rules, enterprise
strategy, and vision. Enterprise architecture includes functional and
operational aspects. However, it does not address how a solution makes use
of these functions.
___________________
So how does the concept of enterprise architecture bring us closer to our
goal of developing a wider business vision? It brings enterprise strategy,
business, information systems, and technology, all together, into our thinking
or perspective. That's in sharp contrast to our earlier way of looking at
information systems. Now we can see that information systems are just a
tool in the hands of business.
We have two more areas to consider before we even think of designing or
implementing information systems: the organization's strategy and business
architectures. We must take into account business and strategy before we
come to information systems. Whenever you think of a software component,
first think of business objectives and strategy. So we see enterprise
architecture is a broad concept, which includes everything that is required to
successfully run an enterprise—something practically impossible without our
mighty information systems.
The Role of Business Patterns
As an information systems designer, you should make use of your
organization's strategy and business plans as inputs. When it comes to
design, we often hear of design patterns called runtime patterns. Runtime
patterns are used while coding applications and they can be used again in
different situations. These were pioneered by the “Gang of Four” (in Design
Patterns (Addison-Wesley, 1994) by Erich Gamma, Richard Helm, Ralph
Johnson, and John Vlissides), as they are widely referred in literature.
5
Runtime patterns are technical in nature and much different from the
business patterns that we will need to identify in our journey to develop a
strong business perspective. Yet they do have some similarities: both cash in
on the knowledge accumulated by our designers, and both are reusable
components used in the design of information systems.
A business pattern is a set of generic models and rules used by system
designers to create and define business solutions at a high level. Business
patterns can be used as a common language to discuss the business
architecture between functional or subject matter experts and software
designers. Business patterns describe solution architecture patterns at
different levels of abstraction. They are a set of reusable assets that can
speed up the process of developing simple, end-to-end e-business solutions.
Business patterns define, at a high level, the interaction between end users,
businesses, and data. They also identify the high-level participants who may
be involved in a solution.
Here's an example: think of the self-service business pattern that you find in
an online marketplace like eBay or Amazon, and many other e-procurement
sites. These solutions enable users to access systems directly in the form of
business processes and underlying data. No intermediary like an insurance
agent or a broker is involved. Another example of a business pattern is a
single sign-on function that provides access to multiple back-end systems.
Likewise, a collection of reusable business patterns can be used to define,
assemble, and communicate a business solution quickly.
A series of business patterns are likewise available as architectural and
design best practices that can be reused to minimize the overall risk of our
projects. And they also help us reduce the time to market. Both line
managers and system architects treat business patterns as common
blueprints that facilitate their working together to arrive at more agreeable
business solutions.
Challenges to Your IT Organization
As we broaden our horizon, it might help to know the typical challenges
faced by your own IT organization or that of your client. As you might guess,
all challenges revolve around the large number of applications and interfaces
that a corporation typically has. Challenges include the following:
1. A large and disparate IT system that is “silo” based (applications
are in relative isolation from each other).
2. A large number of running applications on various platforms and
technologies. These include multiple ERP systems and a variety of
homegrown applications developed by various business groups that
have little or no interaction.
6
3. Exact inventory and documentation is missing.
4. Non-responsive and high-inertia IT systems make it difficult to focus
on core business and new initiatives.
5. Multiple external vendors result in high management and support
costs.
6. Most application knowledge resides with the vendor teams who
support and maintain the systems.
7. High costs in maintaining legacy applications, which runs up to 80
percent of the total IT budget.
IT people need to be aware of these challenges to appreciate the viewpoint
of their managers. They need to develop skills to overcome these challenges
so that they can become managers and IT directors in the future.
Figure 1-2 depicts the typical scenario at the IT department of a large
manufacturing company. There are three main ERP systems represented by
vertical rectangles. Smaller systems (System A, System B, System C, etc.)
interact with these ERPs through interfaces and batch processes. The system
of interfaces is very complex and unmaintainable sometimes. The result is
large expenditure on support and maintenance of the whole IT system.
Figure 1-2. Large and complex web of applications and interfaces at ABZ
Possible Solution to Challenges: Lean IT
With all these challenges, what steps are IT organizations taking to become
more responsive and business driven? Traditionally, organizations have
made massive investments in IT infrastructure and incur regular expenses on
maintenance, upgrades, and skilled resources. Even then systems are not
responsive and agile enough to accommodate new business needs and
variations in demand. Lean IT Transformation is an approach to creating
agile, flexible, business-driven, and economical IT service models.
The soul of Lean IT is to minimize waste of any kind and inject small but
continuous improvements into the system. It can be really rewarding for the
enterprise to eliminate waste from business processes by transforming
business operations and adapting to efficient and simplified functionalities.
Incidentally, most of the principles in Lean IT are derived from the time-
tested model of lean manufacturing and Just-in-Time manufacturing
pioneered by Toyota Motor Corporation. It is also often called the Toyota
Production System.
One way to create Lean IT can be to leverage the latest developments in
cloud computing technology with pay-per-use and next-generation SaaS
(Software as a Service)–based business models. These advances are likely to
7
give much-wanted agility to the business and at the same time significantly
reduce total cost of ownership. (However, the pay-per-use model may pose
some initial difficulties for organizations with heavy investments in IT
infrastructure.) A number of hosted services offered by Google and Microsoft
like e-mail, Google Docs, MS-hosted Exchange, and MS-hosted SharePoint,
offer much cheaper options to the corporation than hosting them in house.
These services are hosted and maintained off-site by the third parties. So the
cost and inconvenience of maintaining such things as infrastructure and
interfaces is taken over by service providers. This allows an organization to
concentrate fully on its core business, leaving the challenges of IT to
competent service providers.
Current trends show corporations have already started moving towards Lean
IT. Still there are challenges to realize the full benefits and to manage a
smooth transition. However, with many success stories around, it's worth
taking a risk and offloading some capabilities that seem to sap so much time
and energy. So be a keen observer and follow the developments to lead from
the front. (Note: Cloud computing is covered in-depth in Part II of this book.)
Let's compare Figure 1-3 with Figure 1-2. In Figure 1-3, the IT landscape is
considerably simplified now. The number of ERPs is reduced to one from
three and the legacy systems are also reduced. Now the vertical columns
represent the modules or subsystems of a single ERP. This can only happen
by a reorganization and business transformation in the IT department. The
functionalities of many legacy applications are transferred to one ERP, and
many applications are retired as a result. Interfaces are also reduced and
streamlined.
Short Test: Can You Answer These
Questions?
Having read and thought about the contents of this chapter, you should now
have an idea of how to answer the following questions as it relates to your
project or assignment.
1. What is the business perspective?
2. What type of work am I doing? (Examples include development,
maintenance or support, database administration, etc.)
3. What business problem am I addressing through this assignment?
4. Who are the top stakeholders in my module/project in terms of
individuals and functional groups? Can I list their role in my project
and how they affect me?
5. What is the monetary value of my efforts?
8
6. Can I list the business challenges faced by line managers in my
functional area? Is the current system adequate enough to address
those? If not, what changes are required?
7. Do I fully understand the enterprise architecture concept?
8. How could some of the principles of Lean IT aid my work and the
organizational results?
Summary
This chapter overviewed your job efforts in the larger context of enterprise
IT. The quest to develop a business perspective starts with looking at the
project's connections with the business and the overall IT organization. IT
needs to be seen as a tool to enable the organization to reach its goals. All IT
projects and investments have to be driven by business objectives. When
that happens, business executives see IT organization as a true companion
that helps them in achieving objectives, and not, as is too often the case, as
a stumbling block. This can happen when we, as technology experts, start
appreciating the business perspective of a project.
It might be interesting for you to keep a close watch on the evolving field of
enterprise architecture, which beautifully blends business with IT and
involves everything that makes IT more effective in achieving business goals.
There are a number of online groups that discuss and contribute positively to
the emerging art of enterprise architecture.
Case Study: Migration from NAB to
J2EE Architectures
Over the years, there have been numerous software builds designed to
upgrade older systems, but they have resulted in a patchwork of inconsistent
and, at times, incompatible processes. System migrations can pose a lot of
challenges to IT managers: their need may be questioned by company
leaders; they need high budgets in terms of support and maintenance; and
they may not be well interfaced with other systems (silos).
But systems can be replaced with newer and more efficient applications that
align well with an organization's strategy and newly developed enterprise
architectures. New business integration patterns are being introduced with
an attempt to simplify overall IT operations.
The case that follows presents an example of what goes into a major IT
overhaul—and what the $1 million price tag buys in terms of efficiency.
The Case
9
ABZ is a capital equipment manufacturing company headquartered in
California. It has manufacturing facilities and sales offices all over the globe.
The company's IT organization has an annual budget close to $30 million,
with a large workforce of managers, developers, and contractors. During the
late 1980s, it spent thousands of work hours developing an array of
applications supporting its post-manufacturing activities. These applications
were used for tracking labor availability against demand, time tracking,
configuration data for tools, human resources (HR) records, skill data on
engineers, facilities management, and tool warranties. The applications were
developed by university students and freelancers, so they lacked a
structured approach.
Many software development platforms were used for these applications,
including the Netscape Application Builder (NAB), which was supported only
on Windows NT. With Microsoft withdrawing support from the Windows NT
operating system, it was imperative for ABZ to migrate these applications.
Otherwise, it faced a huge risk in putting crucial corporate data and
processes on the back of a technology no longer supported by its vendor.
The applications originally developed using NAB were migrated first to J2EE
(Java 2 Enterprise Edition) and ultimately to SAP in 2008. This case study
deals with application portfolio migration to J2EE.
Note: There is another case study later in the book that deals with business
transformation and migration to SAP.
The Need for Migration
The biggest factor governing migration was the fact that the NAB tool was
restricted to Windows NT, for which Microsoft no longer provided support.
Work-arounds like VMware were no longer an option and had been causing
performance degradation. The organization therefore made a policy decision
to move all development and production environments to Windows XP. NAB's
development environment was not supported on XP, and the NAB tool had
many proprietary application programming interfaces (APIs) and, further,
was not based on open standards. Standard features like database
connection pooling and database clustering were absent. Also missing were
implicit transaction management and exception handling. The only major
factor that supported the continued use of NAB was its integrated
development environment and strong implicit support of Model-View-
Controller (MVC) architecture. But with Windows NT support withdrawn,
these features became irrelevant. With Java Server Pages (JSP) becoming a
reality in J2EE, developing the presentation tier became a better option than
NAB.
Migration to J2EE was thus a natural choice. It was platform independent and
thousands of mission-critical applications were running on it across the
globe. Given the similarities among applications, there were also
10
opportunities to save money by reusing some code. Plus, the code and logic
of applications developed using NAB were fully readable by J2EE developers.
By that time, J2EE had a good pool of trained developers, a lot of knowledge
base in terms of design patterns, and experience with many applications.
Lots of open source applications that were compatible with J2EE were also
available. Unlike NAB, working with J2EE technologies offered no possibility
of getting locked in with a single vendor.
Figure 1-4 represents the application architecture prior to transformation. It
is a three-tier MVC architecture that is based on a proprietary Netscape
application server. The terminology specific to Netscape is explained next.
Figure 1-4. Existing customer applications with NAB architecture
HTML templates are used to dynamically generate the content used in the
presentation tier. There is a Template Engine that can also dynamically
generate templates based on the type of data. AppLogics are Java files that
are designed in such a way to represent only one business component.
AppLogic files handle input data, access the database, and do the process to
generate data to populate the HTML templates. Business objects
implement the business rules that are used by AppLogics. These business
rules are defined per the application requirements. The GXQ Query files
manage the interaction between Netscape Application Server applications
and back-end data sources. These query files are called from AppLogic or
business logic components.
Proposed Architecture
A simple J2EE-based three-tier architecture was found to be the best solution
to the problem. This MVC-based architecture was simple, proven, and
already used in thousands of applications across the globe. It was highly
scalable to accommodate the growing needs of the organization. It
supported application and database server clustering. Loosely coupled
layered architecture helped ensure high maintainability. The business tier
and Data Access Objects (DAO) could later be replaced by technologies like
EJBs (Enterprise Java Beans) and object-relational (O-R) mapping tools.
The following industry standard design patterns and constructs were used in
building the system. This further added to performance, standardization in
construction, and maintainability.
Value Object Pattern
Data Access Object Pattern
Business Delegate Pattern
Singleton Pattern for Caches
11
Façade Pattern
Service Locator Pattern
Front Controller Pattern
Role-Based Security
Database Connection Pooling
Data Transfer Hash Map
Data Transfer Row Sets
The legacy application was enormous but relatively simple in business logic.
Huge graphical user interfaces (GUIs) interacted with databases, with very
little processing in between. The application was very mature and there was
very little scope for further evolution. This all indicated the need for simple
but robust architecture that was fulfilled by a proposed simple, three-layered
MVC-based architecture (see Figure 1-5). There was no need for distributed
architecture with EJBs.
Figure 1-5. Proposed J2EE architecture: logical view
To connect to the database, the choice between using JDBC (Java Database
Connectivity) or O-R mapping tools needed to be made. O-R mapping tools
are known to automate the query writing and other features required to
connect the business layer to the database. In this case, most of the
database queries were already available in the existing legacy applicator, so
the automation feature of O-R mapping tools was not desired. The queries
were too complex for any O-R mapping tool to handle. So the option of DAO
was chosen to work with JDBC, despite the increased length of code that
needed to be written manually. The DAO layer provided a desired loose
coupling between the business logic and the database. Later on it was
possible to migrate to any advanced O-R mapping tool.
The Transformation Approach
The three-tier MVC architecture of NAB was replaced by a similar three-tier
J2EE architecture. In the modified architecture, the front-end component of
NAB was mapped to JSP, the middle tier to Java classes, and the database
queries to JDBC-based Java Data Access Objects. Table 1-1 provides a
mapping between NAB and J2EE components. The following list describes the
exact component mappings.
JSP-based Presentation Tier to replace current NAB
Templates/PresentationGX tag support in JSP is not available
NAB Templates to be converted to use standard JSP tags and
syntax
12
Using struts in the Presentation Layer to ensure adherence to MVC
architecture. There are many standard design patterns that are
built into its standard struts framework
Redesign the NAB AppLogic components to Java classes of J2EE
Business Tier
NAB's Data Access logic to be migrated to J2EE's JDBC APIs
Resource Tier (DB): The strategy to reuse the existing stored
procedures and DB schema
Table 1-1. NAB to J2EE Component Mapping
Architectur
e Layer
Existing
NAB/NAS
Components
Replaced
J2EE
Components
Description
Presentation Logic AppLogic JSP/Struts “Controls the application's interface to the user by
processing requests, generating content in response,
and formatting and delivering that content back to
the user.”2
Presentation Layout HTML template JSP “JSP are HTML pages that contain embedded Java,
and thus are much more versatile and powerful than
existing HTML templates.”3 They form the User
Interface component of the application.
Business Logic BussLogic Java Classes in the
Business Tier
Controls business logic. These Java classes allow
business logic to be continual across calls. They offer
improved caching, and also work with JDBC for
making database transactions.
Data Access Logic JDBC (without the
Connection Pooling feature)
JDBC APIs (Connection
Pooling feature)
“Controls database storage and retrieval. The JDBC
API is available to all Java components.”4 All database
transactions are usually controlled by the Business
Tier Classes.
Outcome of Transformation
This transformation exercise represents hundreds of such technology
upgrade projects across the globe that are undertaken to improve business
processes in an organization. With the NAB-based application, the client was
at risk of running its mission-critical business processes on an obsolete
technology platform. This exercise not only provided a required technology
upgrade but also provided a golden opportunity to upgrade the obsolete
business process to global standards. Application interfaces to other systems
13
were simplified and the overall maintainability of the application was also
improved.
___________________
The following points summarize some of the benefits that were immediately
realized as a result of this upgrade.
1. Moved application from obsolete NT to the higher versions of
Windows
2. Adopted an open standard, robust and scalable J2EE architecture
3. Easy availability of skilled resources and easy maintainability
4. No locking with a single vendor
5. Code reuse
6. Utilized the experience and knowledge base of thousands of
existing J2EE installations
The company's business leaders were very appreciative of the outcome. The
huge risk of carrying critical applications on an obsolete technology platform
was mitigated. The J2EE-based application introduced measurable
performance improvements for end users. Due to the availability of skilled
resources in J2EE, maintenance and enhancements were no longer an issue.
The company expected to see monetary savings and improved business
processes.
