Enterprise System Architectures

Building Client Server and Web Based Systems

Mark Goodyear, Mark Goodyear

• Publisher: CRC Press
• Year: 2017
• ISBN:
  9781351450799
• Edition: 1
• Topic: Ciencia de la computación
• Subtopic: Tecnología de la información

Experts from Andersen Consulting show you how to combine computing, communications, and knowledge to deliver a uniquely new-and entirely indispensable-competitive advantage.Lead, Follow, or get out of the way
Your company's ability to sustain a competitive advantage is in jeopardy. Your competitors can imitate and improve faster than ever. You need to find ways to help your company discover and deliver and astounding solution, control its costs, and move on the next astounding solution.Web-based computing is the vital technology enabler for today's most important business opportunities, like E-Commerce. It is also the flexible foundation for future solutions. However, because of the complexities and difficulties it represents, it can be critical hurdle for IT shops and for an entire business. Enterprise Systems Architecture: Building Client/Server and Web-Based Systems is your guide through these complexities as you integrate your technology capabilities with your strategy, people, and processes to deliver astounding solutions. It

• Introduces you to basic principles and concepts, provides an overview of state-of-the-art in client/server and Web-based computing models, and develops a solid business case for implementation.
  
• Acquaints you with various technologies involved and describes a comprehensive network computing architecture.
  
• Details crucial analysis, design, and implementation issues, including design specifics for architectures, applications, and network; rollout strategies; and ongoing management of distributed operations.
  
• Explores emerging technologies and their likely impact on the future of netcentric computing.Here you'll find detailed information on the architectures and frameworks for network-based computing strategies for designing and implementing solutions strategies and methods for security. It also provides a full framework for testing applications, and in-depth dis

Section III

Designing and Implementing Netcentric Solutions

Chapter 15

A Framework for Netcentric Implementation

As organizations move to client/server computing, and then to the more complex dimension of netcentric computing, they do not always carefully think through issues associated with successful implementation. Because of the distributed environment, client/server and netcentric applications are more complex and difficult to implement than traditional applications.

Successful delivery of netcentric solutions depends on the following key areas:

• Project organization

• Technology architecture decisions and implementation

• Application design and implementation

• Network design and delivery

• Site preparation and installation

• Systems management

• Change management

These areas interact with each other in a flow of work, depicted in Exhibit 1.

NETCENTRIC PLANNING CHART

These workflows can then be fleshed out into a comprehensive planning chart for netcentric development projects (Exhibit 2). This planning chart has been used successfully on hundreds of such projects around the world. Each box in the planning chart represents a work segment to be done to address one or more netcentric implementation issues.

The arrows and lines suggest a sequence as well as an interdependency of the efforts. The completion of a segment usually means that a major work deliverable has been completed.

Exhibit 1. Primary Flows of Work.

The diagram is complex because a complex set of interrelated problems must be addressed. At the same time, the exhibit is still at a conceptual level because it does not show all the interrelationships or the actual work tasks to be done.

This chapter provides an overview of each of the major development streams within the overall planning chart. Subsequent chapters within Section III of this book go into more detail on each of the streams.

PROJECT ORGANIZATION: ROLE OF KEY MANAGERS

Defining organizational structures can be a high-risk undertaking. Such structures often imply a change in who is in charge, a change in goals, and changes in how work is to be done. Put another way, organizational structures strike right where people live. As such, organizational charts tend to be the source of a great deal of concern and, on occasion, angst. However, the fact remains that to undertake the development of a netcentric or advanced client/server system, organization must be a key concern.

Exhibit 3 depicts a generic organizational chart. It is high level, but it provides a starting point for a netcentric or client/server development effort. Many other factors have to be compared against this sample before an organization can come up with its own usable model. These factors include the skills of personnel involved, their desires, their past histories, and their expectations.

Exhibit 2. Netcentric Implementation Planning Chart.

The size of the project must also be taken into consideration. The organizational structure discussed here is applicable to projects of roughly 150 to 200 people or fewer. For larger, more complex engagements, additional roles come into play — roles such as an overall architecture strategy function or an enterprise architect — which are concerned with coordinating the functional, technical, and business aspects of the system. These roles are outside the scope of this book, although Accenture has additional methodologies for these larger projects.

Strategy Manager

The structure shows a single overall leader for the project — here, the “strategy manager.” There is a great deal of value in having a single individual responsible for, and with authority over, the project as a whole. Such individuals, when they welcome the responsibility, seem to bring to the effort a commitment and concern that is lost when the project is divided among multiple leaders, each with a mix of concerns, constituencies, and objectives.

Exhibit 3. Organizational Chart.

Program Management

The program management role appears as an adjunct to the strategy manager. The role of this group is to monitor all the projects that are being pursued to deliver a netcentric or advanced client/server application. This monitoring function involves more than just tracking overall status. It also includes evaluation of the quality of the deliverables as well as their cost-effectiveness.

Even when program management itself does not have the direct responsibility for quality review and approval, this function is responsible for ensuring that these reviews occur and that they are done by qualified people.

Also, if one or more strands of the work start to run late or encounter difficulties, it is program management’s responsibility to note the issue, evaluate its impact, and pull together strategies to deal with the situation.

Finance and Policy

The organizational chart also shows the finance and policy group reporting to the strategy manager. This group tracks overall spending on projects and verifies expenditures as time passes. A development project often places new demands on organizations, and new policies to deal with these demands have to be devised.

For example, a netcentric engagement may be inherently distributed and require that people be on the road for extended periods of time. The company may have limited policies on reimbursement of expenses and handling of costs that need to be expanded for the project. This expansion would fall to the finance and policy group.

The next level of the chart shows organizations more focused on the actual building and delivery of the applications.

Applications Development Manager

Often, a netcentric development project addresses several business applications such as multiple lines of business and related claims. Each of these applications may have its own project manager. These project managers then report to the applications development manager.

The applications development manager has the overall responsibility to deliver the applications in accordance with time, budget, and quality standards. As such, this manager can make decisions about redeploying resources between applications and also provide a single voice to the business users and to the rest of the project teams about the applications development process.

An interesting question here is whether large application projects should have direct access to the strategy manager or report through an applications development manager. The first issue here concerns span of control.

Even with the relatively simple reporting structure shown in Exhibit 3, the strategy manager has five direct reports, as well as the program management and finance and policy groups. This is often near the limit of effectiveness of the strategy manager. Second, experience suggests that the applications often have a natural set of related concerns that are best resolved by bringing them together under one individual who makes the decisions necessary to get the job done. A common example of such a concern is the need to move resources between different application teams. Each team manager may have difficulty giving up the resources, but the applications development manager can take the broader view of what is best for the suite of applications as a whole, and can make the hard decisions on moving resources.

Technical Manager

The technical manager is responsible for delivering the technical components of the application. As noted, larger projects will most likely have a function or role concerned with overall architecture strategy. On projects of the size discussed here, the technical or technology manager will handle overall architecture questions, working between groups and within his or her own group. A number of key technological areas report to this manager

• Architecture. The architecture function is responsible for the delivery of key architecture components, including the development and execution architectures.

• Data. Netcentric projects often involve difficult decisions about the design and allocation of data across multiple nodes and between multiple applications. Often these decisions must be made at the conceptual, logical, and physical levels. There also may be difficult data administration and security demands. Responsibility for addressing these issues falls under the data area.

• Network. The logical and physical networks play a dominant role in netcentric development. There should be a group devoted to the design and implementation of these networks, and it should report to the technical manager.

• Operations. The operations group has responsibility for implementing the operations architecture. Often, the operations group is also responsible for operating the system in the first few iterations as the system rolls out. Experience shows that an operations group, knowing that it will have to operate what it implements, tends to produce better answers. As suggested elsewhere the operations architecture is very dependent on the definition of Service-Level Agreements (SLAs) and Operational Level Agreements (OLAs). Also, this group has extensive interaction with the Architecture group described previously.

Some interactions among these groups should be noted. Both the data group and the network group, for example, can be used to illustrate some worthwhile points. First, although these groups report to the technical manager, their work lies in working with the applications. As a result, most of their time should be spent moving among the applications where they are responsible for the data design and network design for the applications. This responsibility includes ensuring the quality of the design, its timely delivery, and the design’s ability to meet current demands and evolve for the future. Further, much of the evaluation of the individuals’ contribution to the effort should be made by the application team managers with whom they work.

The groups report to the technical manager primarily because much of what they decide has a significant impact on the overall technical approach. Changes are best addressed through the technical manager.

Second, because the groups report to the technical manager, they have a person who can resolve conflicting technical issues. For example, if the data design group comes up with a database design that must pump large volumes of information through the network, causing unanticipated impacts on network performance, it may be left to the technical manager to resolve the conflict.

Change Management

Change management is responsible for moving the user community through the change process. In this role, change management must interact a great deal with the applications group. However, change management must be viewed by the business community as a conduit to make sure that concerns and issues are being heard, and that changes are made based on the trial, evaluation, and ongoing use of the systems.

In some cases the change management group has reported through an entirely different line, often the user community structure. The risk with that reporting structure is that the change management group may become a defender of the status quo rather than an active advocate for change.

Site Preparation

The site preparation group is responsible for preparing the site for a release of the applications. In this role the group addresses the management of the upgrade of each site and the installation of hardware, applications, and procedures in preparation for taking the site live in the rollout process.

Rollout

The rollout group has responsibility for ensuring that the systems function successfully as each site comes on line, which often means managing conversion of data, completion of go-live checklists, and completion of any miscellaneous tasks that are still outstanding. With early sites this group may be physically present as the site goes live. However, as experience builds, this group can increasingly work from a remote site and still deliver successful installations.

This management structure is a basis from which a project can develop a structure appropriate for its own unique circumstances and needs. The process of defining such a structure can be time consuming and difficult because of the many concerns that organizational change bring about. However, it is fair to say that without an appropriate organizational structure the question of success in implementation will be left too much to chance.

The remainder of this chapter walks through each of the development streams (reproduced in Exhibit 4). More detail on most of these streams is found in the remaining chapters of Section III.

Exhibit 4. Primary Work Flows.

CHANGE MANAGEMENT

The cost and difficulty of netcentric and client/server...