Architecture

EDBOK Guide

What is Architecture?

Architecture provides the framework to describe the proposed solution for the project at hand. The definition of the Architecture should occur following the Needs Analysis, Technical Analysis and Business Analysis phases and is the point in the process where the technical and business choices are established.

The technical and business options and then make a choice on which particular technical solution we will design and which budget plan that we will adopt and test our results against.

As William Broddy, m-edp, has noted, “This is where the horse-trading takes place.” That is, there must be give-and-take between what is possible and what you can afford to arrive at what the company can settle on as a proposed solution that gives the company the “most bang for the buck.”

Architecture is the initial, high-level description of that final proposed solution.

Architecture – Large or Small

The Architecture that describes a proposed solution may be large or small, just as the problems it is intended to solve may be large or small.

Consider the project to make a required regulatory language change to a paragraph  in an insurance policy. Because the infrastructure of the solution already exists, the size of the proposed solution to be described is quite small: you change some words in a document object in the composition system’s document object library, print it out to see if it displays correctly, then begin the rigorous regression testing to ensure that you have the correct results for each case. As projects go, this requires little thought or decision-making.

Now consider the project that is replacement of a number of home-grown COBOL programs that generate line data with a modern, multi-platform enabled composition product that generates the latest full color print stream with an infinite number of fonts, images and graphics, with add-ons for dynamic composition at run-time, and message management. In real life, such projects totally overturn the document production workflow from stem to stern and can take a number of employees or contractors more than a year to design and implement.

Thus, with Architecture, there is no “one size fits all”. Rather, the size of the result of the Architecture phase will be as big as it needs to be.

Financial Side of Architecture

In the Business Analysis phase, we look for the money to underwrite the project by making estimates on how the future system might work and determining (“guessing”) how much money the new system might save over a period of time – which money could be applied to the new project as part of its ROI calculation.

However, in the Business phase, we can’t be sure which technical solution will be adopted so we may have to make a number of calculations based on a variety of technical solutions.

Now in the Architecture phase, based on the technical solution selected, we can develop a budget and review that budget to make sure that it matches the estimates produced in the Business Analysis phase.

In finalizing the project budget we will:

• determine the projected cost,
• determine what we can afford to do (and make sure that one matches the other),
• find funding if necessary for any external expenditures,
• find funding or people for the development project team, and
• secure all approvals to proceed into development.

Technical Side of Architecture

In the Technical side of the Architecture phase we have several tasks to perform in the process of choosing the final proposed technical solution:

• assessment of current technology,
• development of application workflow,
• identification of enhanced or replacement technology, and
• development of the project plan.

These items require a detailed evaluation of processes and practices versus best practices, as well as an impact assessment against other processes or to the resource pool.

It is critical to note that any proposed technical solution as embodied by the Architecture must include an understanding of how the current Architecture functions. How can you determine in advance if the proposed solution will do what you need it to do if you don’t know what the current system does, and why?

What Can Go Wrong

Indeed, not understanding what the current system does and why it does it is the source of the most insidious errors in many projects. Because the focus of most eyes in the project is on what is “going to be” it frequently happens that, while the new project correctly delivers on the new features, it inadvertently breaks a one or more important features in the current system causing the new project a serious problem, if not a disaster.

One life insurance company thought that they would replace their 1960s era policy issue system with a more modern system. Their original system was a series of custom programs written in IBM 370 Assembler. The programs were hard to maintain as the original author had left and additional Assembler language programmers were difficult to find. In addition, since it was written for a mainframe environment, there was no built-in GUI for managing the system. All online controls had to be written in a separate CICS system updating a custom database.

The company decided to buy an off-the-shelf client-server-based policy issue system. This system came with its own databases and GUIs which more easily fit into the evolving distributed environment that the company preferred. The company spent two years and thousands of hours making the changeover as there was a huge amount of customization that went into the new system.

At the end of the changeover, only half of the several hundred life insurance products that had been supported in the old system could be migrated into the new system.

Why? Because there were dozens of features in the old, custom-written Assembler- based policy issue system that was not in the new off-the-shelf client-server system. Because many of these features had never been cataloged in the old system the lack of these features was not discovered until the formal QA process began.

When it was discovered that a large number of life insurance products could not be generated correctly, a number of previously viable products were dropped and another year or two was added to the overall project as additional code and workarounds were implemented. This caused a huge cost overrun, as well as the unknown opportunity, and lost cost of the previously viable products that were dropped – all because the company didn’t fully understand its current architecture before it embarked on the project to completely replace it with a new architecture.

Participants

Just as the size of the Architecture will vary greatly based on the side of the problem being solved, so will the number of participants.

At a minimum you will have:

• the architect / technical consultant,
• financial planner, and
• key stakeholders.

The architect/technical consultant will represent the technical aspects of the proposed solution while the financial planner will represent the business aspects of the proposed solution. Even if there is already an assigned a project manager, that project manager will rely on both technical and business advice in determining and describing the most appropriate solution.

As the size of the project being “solved” by the Architecture phase grows, so does the number of people who become involved. Some key roles include:

• Document designer: The person who knows the technical details about either the required changes to the document or about detailed interworkings of the new composition tool being proposed,
• Database specialist: For identifying obscure data base fields that will now suddenly acquire a new significance, or for creating a new system or “shadow” data base, or modifying current data bases already in production,
• Operations analyst: To review and describe to changed or new manufacturing workflow,
• Managers of previous and next steps: For situations when completely new elements are being added to the document composition workflow – such as a new printer or a new composition system,
• Vendors: Both hardware and software, as appropriate, as well as any professional services,
• Financial players,
• Document / budget owner: This would be the lowest level of manager whose budget is responsible for the project,
• Procurement: If the project is large enough to require the intervention of a procurement office, and
• Corporate or divisional finance: Almost certainly required when enterprise software or any electronic printing/finishing hardware is acquired.

Vendors

In the Architecture phase, vendors can be an invaluable source of information. A vendor who has sold you a substantial amount of hardware or software has a strong vested interest to ensure your happiness with their product. Indeed, the smaller the vendor,    the larger the need to keep you happy.

Second, the problem that you are trying to solve has almost certainly been solved by other companies on your industry. That is, for every 1% of the companies that are “bleeding edge”, there must be the 99% of the companies that are merely following in their footsteps.

And, if you think about it, when vendors gives you recommendations of fellow user companies to speak to they will give you companies who successfully implemented the new hardware/software. It’s one thing during the sales process to want to also hear from customers who had problems with the proposed hardware/software, but once the decision is made, you’ll want to know more from the users who made the acquired products work.

With luck, you may be able to get “sanitized” architectural documents through the vendor for your particular project, either because they were created by the vendor’s implementation team or were derived (with permission) from the documents of some of their other users, properly cleared of any proprietary information.

In this same way, note that trade associations can help fill in the gap in finding fellow users with similar experiences to the project that you are intending to undertook. While it may happen that there are not any users of the similar hardware or software in your immediate area, trade association meetings can attract regional or even national audiences.

Xplor International is the trade association that represents users and sellers of transaction document production hardware, software, and services. At Xplor events there will be other users of your proposed hardware and software, and there will possibly be open sessions describing how to use the product.

Furthermore, one not commonly discussed advantage of having multiple vendors at a trade exhibition is that the vendors are less likely to be spinning fairy tales to you, since they know that you will be speaking to other vendors just a few feet away…or worse, one vendor is speaking to an audience while on a panel in front of a group of other vendors, who would quickly set the record straight if anything amiss was said.

What is the End Product?

The end product of the Architecture phase is, of course, the Architecture. This is, as noted before, is the high-level description of the single proposed solution that the company has decided to pursue. It may not be the cheapest or the fastest or the technically most sophisticated or even the solution that gets you everything you want, but, at the end of the discussion, you realize that this is the solution that gives you the “mostest” with the resources that you have.

Thus, the end product of Architecture will have:

• budget (i.e., how much will this solution cost to develop, so that future expenses can be measured against it),
• resource plan (what employees and long-term contractors will be need for how long to complete the process),
• new process in terms of workflow,
• clearly and cleanly integrated with current process (yes, don’t just describe the proposed process but also describe how it fits in with what you’re doing today that is not going to change),
• a description of the expected output,
• specify version / release of software/hardware, and
• generally scope out custom work for either internal or external services.

Who Needs to Approve?

The number of individuals required to approve the results of the Architecture phase will vary considerably, based on the size of the proposed project.

At a minimum, of course, the “owner” of the project must approve the results. This could be the manager of the business unit that owns the document application that was having a small update.

Larger projects will require the approval of each group that is touched by the changes in the project, and in some cases, by groups that are not directly touched by change but who may be affected by upstream changes.

In addition, external groups that are part of the large project planning and execution (such as the project office or accounting office) may also need to approve based on the policies and procedures of the company. Indeed, for company critical projects, the Architecture phase may have to be approved by a senior vice president.