Let’s return to the example of the integration between the front-end commerce system and the back-end order management system. In Chapter 10, “Managing Requirements,” we described a technical decision that must be made by the architects responsible for integration of the commerce platform with the company’s back-end order management systems. This choice is illustrated in Figure 11.1.

Figure 11.1. Two options for back-end integration

The first option is for the commerce system to simply capture the order and to transfer it to the company’s order management system, which is responsible to approve payment and then manage the order until it is fulfilled. The second option is for the commerce system to hold the order until payment approval is granted, and only then transfer it to the order management system for fulfillment.

Both these options might be technically feasible, and you would intuitively expect the designers to make the decision about which option to follow based on their technical skills and experience.

However, even though this decision seems technical in nature, it can have far-reaching implications on the business processes that the company follows. For example, say option 2 is chosen in which payment is approved by the front-end commerce-end system. This technical decision would have several implications that have little or nothing to do with technology but affect the daily lives of line of business personnel.

Imagine a situation where an order is placed, and then the customer calls a customer service representative to inquire about the order or to modify it. The first thing that the customer service representative would need to do is to find the order. If the payment for the order has already been approved, the order would be located in the order management system, and it should be modified there. However, if the payment has not yet been approved, the order must be located in the front-end commerce system and changed there. Obviously this search for the order could become quite complicated and would become both confusing and time-consuming for the customer service representative.

In an environment where the performance of customer service representatives is closely monitored, every second that these employees must spend with a customer is important. The business is interested in reducing the time spent per customer, whereas this technical decision causes the productivity to go down and hence the cost of customer service to go up.

If the designers are aware of the issue, they can come up with ways to deal with it. For example, they could design the order management tools with enough intelligence to automatically find the correct place where the order is to be edited. However, they would do this only if they were aware of the business implications that stem from their design.

Now imagine that one of the goals of the system is to allow marketing administrators to preview their site with their planned marketing campaigns; in other words, to view the site as it will look when the campaigns are active in the future. A naïve business analyst would transcribe this requirement as follows:

Such formulation of requirements might not be easy to implement. Although this capability has been achieved in some commerce systems, it is technically challenging for a site to treat time as a variable. Normally, the operating system provides only one clock, and this clock applies to all users who view the site, whether they are administrators or customers. Technically, this “future preview” requirement implies that the commerce system treats time as some kind of a variable, which can be set by an authorized administrator within his own context, without affecting other users of the system. In the example, when the administrator views the site, time is set to November 15, while for all other users, time is November 1.

The treatment of time as a context-based variable, rather than as an inherent property of the system, would have impact on many components of the application. For many commerce applications, this would be either impossible to achieve, or the development effort might be quite large and expensive.

If the business analyst had some understanding of technology, he would avoid formulating the requirement in such a technically challenging manner. Rather, he would perhaps work with the marketing department that originated the requirement and modify it in a way that makes it easier to implement, such as in the following example:

The second formulation of the requirement does not demand that the administrator view the site as it would look in the future. Instead, it says that the administrator needs to view the site as it looks today, with the particular future marketing campaign shown.

This difference with the first requirement is subtle but significant. For example, let’s say that this site has several campaigns scheduled to start in the future; one starts on November 10, another on November 15, and the other on November 20. Furthermore, several campaigns that are effective today expire some time before November 15.

Based on the first requirement, the administrator would see the site exactly as it would appear on November 15, with only those campaigns that are effective at that time. Somehow the commerce software must be made to think that all the current campaigns have already expired, and the two new ones are effective, while the one slated to start on November 20 is not shown.

On the other hand, with the second formulation of the requirement, this manipulation of time is unnecessary. All that is needed is to show the site exactly as it appears today, with the current campaigns. The only difference is that in addition to the current campaigns, the requirement is asking to also show the new campaign that is scheduled for November 15.

Depending on the commerce software used, this second formulation of the requirement might be much easier to implement. It involves modifications to the engine that runs the marketing campaigns on the site but does not involve a complex redesign of the interactions with services provided by the operating system.

We see that the business analysts that set requirements for the commerce system must have some understanding of the technology that is used. With such understanding, they can better formulate the requirements and prioritize them to make the release of the system more achievable.

Now we discuss some specific skills necessary to the commerce project and see how they operate—and especially how they interact with each other.

The project manager is truly the glue that holds a multisite project together. The project manager must not only track the progress of line items, but also monitor the overall health of the project. For example, a lack of communications between different implementation teams could ruin the entire project, but it might not be discovered until the line items are missed or until a huge number of defects are discovered during testing.

Example of a Project with a Fatal Lack of Communication

A company in Canada was trying to implement a new order management system for all its sites. The requirements were clearly specified and included capability to automatically find suppliers for each item in the order, and to create purchase orders to the suppliers. The order management system was supposed to maintain communications with suppliers, including confirmations of shipments or nonshipments of portions of the orders.

After many months of development, about a month before the planned deployment date, management learned that system test was failing and that the system cannot perform the critical tasks of splitting orders among the suppliers and tracking the progress of fulfillment. This late in the cycle, the problem aroused great concern among the executives.

It is instructive to understand the exact problem, so we will dive a little into the technical details here.

The problem was investigated by an outside consultant, who found that the new order management system was being developed on two floors of the company’s offices. On the third floor dwelled the programmers who developed the programs for the new system, including the business logic to select the suppliers for each order. These programmers also designed and implemented the processing of incoming messages from suppliers regarding the status of orders handled by the suppliers.

On the second floor were the developers of the message gateway, whose job was to make sure the messages coming from the suppliers are translated to the company’s internal format. The second floor also housed the testers of the system.

The consultant first spent time with the programmers on the third floor and examined the business logic that they implemented. Barring a usual number of defects, the programming seemed to be correct and in accordance with the requirements. The consultant noted that there was great consternation from developers who could not understand why testers were complaining that the system was not working.

The consultant then went to the second floor to see what the perceived problems were from that point of view. The testers demonstrated how they simulated a message coming in from a supplier, which indicated that a partial quantity of the item was shipped, while the rest was not yet determined. The defect was that this message caused the remaining quantity to be reassigned to a second supplier by the order management system, rather than waiting for confirmation from the original supplier. The testers were frustrated that the third-floor developers kept insisting that the system was working as designed, when clearly they saw incorrect behavior.

Eventually it turned out that the problem was that the message mapping done on the second floor interpreted messages by understanding the requirements differently than the developers on the third floor. You can see the message flow in Figure 11.2.

Figure 11.2. Messages between a company’s order management system and the supplier

An order is submitted by the customer, and the order management logic decides to send a portion of the order to a certain supplier. The supplier replies that out of this quantity of items, it is able to ship only a subset—so it might acknowledge only a partial quantity of the ordered items.

When a supplier acknowledged 2 out of 3 items, the message mapping logic written on the second floor interpreted this to mean that the status of the remaining item is yet to be determined. However, the business logic written on the third floor assumed that the remaining item was never going to be shipped and assigned it to another supplier.

Because the testers worked on the second floor, their interpretation of the message was the same as that of the message mapping people who worked in the same hall. In other words, they understood such partial acknowledgment to mean that this supplier will still respond to the remaining item. However, the order management software had assumed that a confirmation of a subset of the items means the other items are unavailable.

In the test scenario, the original supplier would then send a second message to confirm the remaining item. The order management software written on the third floor didn’t know what to do with the second confirmation because as far as it was concerned, this original supplier was no longer responsible for the item.

This scenario is quite complex, and the errors were the result of miscommunication between the two development groups. Given the complexity, it is difficult to tell which one of the groups was responsible for the mix-up. The important question, however, is not whose fault it was, but why such basic miscommunication was never discovered until one month before planned completion. If the disagreement between the groups had been known earlier, the problem would never have occurred, saving much aggravation and time. It is therefore important to devise development processes that minimize the chances of this confusion going unnoticed.

In most development organizations, it is the responsibility of technical leaders to review the designs and ensure that they are consistent with each other. However, in a large project, it is unwise to rely only on the technical leaders to catch all the mistakes—after all, even the best designers and architects are only human, and they could miss details that are only hinted at by design documents. Moreover, in the case of our example, each of the teams had its own designer, and it was the designers who miscommunicated with each other! The team leader of each floor approved his team’s design because he did not notice the subtle difference with the other team’s design. At the same time, it is virtually impossible for the single architect who is responsible for the entire project to review every design detail and to catch every misunderstanding.

Without completely exonerating the technical community, we can at least understand from its point of view how the mistake could have been made and not caught early during design reviews.

Most likely, the high-level architecture of the message flow was unclear or not detailed enough. Because of this, the architecture was misinterpreted by one of the development groups. The resulting error in design was missed during design reviews. In other words, clearly, this company’s design and review processes were flawed.

The question remains: What could have been done differently that would have avoided this miscommunication, or at least how could the miscommunication have been detected earlier?

We would like to suggest that one critical missing piece in this project was the attention by project managers to the health of the development organizations. The project managers deemed their job to consist of tracking a set of various activities, such as designs, development of line items, test plans, and test execution and simply recorded the progress as reported to them by technical developers and testers. Each development line item corresponded to a row on the project spreadsheet, where the “expected date” represented the plan, and the “actual date” represented the actual completion of the line item. From their point of view, the project managers focused on ensuring that all the actual dates in the project spreadsheet met with the expected dates. If the dates were not met, their job was to yell at the relevant developers and testers to get their act together and deliver line items on schedule.

However, the job of project management should not be reduced to just being the taskmasters of the project. Particularly when several different departments are involved, project management has the unique position in which they are able to communicate with all parts of the project effort, and this position must be used to ensure the various communities work together smoothly.

In the case of the failure in our example, it seems clear that the third floor and second floor developers never talked to each other during the entire development effort, and never compared notes on their understanding of the requirements. Effective project management would have noticed this lack of communication and asked the relevant technical leaders to ensure that they spend some time to compare their understanding of the requirements. This communication was not in the original plan because the problem was not foreseen; however, project management should have forced the necessary communication while the project was in earlier stages. Such a basic review of requirements might have taken one or two days out of the project schedule, but it’s better to spend the time early on than to risk project failure later.

The same consideration applies to any large project. However, when creating a common commerce platform for a company, this point is even more important. This large project is bound to involve departments from different parts of the company, which prior to this project might not even have been aware of each other’s existence. Effective communications between the departments is essential to the success of the commerce platform. Project management should be concerned not only with ensuring all line items are delivered on scheduled, but also with monitoring the health of the overall effort. In particular, project management must monitor the communications between the teams and ensure that there is healthy interaction between them.

Furthermore, it might even be a good idea for project management to put together a communications map that outlines all the different departments and organizations involved in the project. An example of such a map is shown in Figure 11.3.

Figure 11.3. Elements of a communications map for creating a multisite commerce platform

This map lists the various organizations and the kinds of communications that take place between them. With this map, project management can anticipate the kinds of communications that must take place to ensure that these communications are healthy.

There are many methods of monitoring the health of communications. For example, project managers can conduct regular interviews with leaders of various departments to get their perspective. Alternatively, the project plan can incorporate checkpoints for exchange and review of the designs, for comparing the business processes that result from the designs, or simply for plan synch-ups. At such checkpoints, representatives of selected departments would come together to compare their plans, their understanding of requirements, and the implications of their designs. This way, any communications issues would automatically float to the surface.

Another way in which architects and designers are crucial to the success in creation of a single platform is by helping guide the business to shape their requirements. Typically the lines of business express their requirements based on their understanding of the business, using their typical terminology and approach. If such statement of requirements were to be taken literally, and everything requested by the business were to be implemented exactly as stated, the effort could be huge. However, frequently it is possible to slightly modify the requirements in a way that is acceptable to the business but which also makes it much easier and cheaper to implement.

For example, say the business is creating sites for different company divisions, with each division specializing in a specific set of products. Different divisions have completely different order management processes, and it is impossible to merge them all onto a single site. At the same time, the company wants to present a single face to the customer, and asks to create a new site that allows the creation of a single-order containing items from different divisions, as shown in Figure 11.7.

Figure 11.7. Division specific sites and combined cross-divisional site

Taken as is, this requirement seems difficult to implement. Because each division does its own order processing and fulfillment, even checking out such a combined order might be impossible. For example, one division might require the buyer to specify where the product is installed and allows tracking of the serial numbers of the products. On the other hand, the products of another division may not have such details. Another example could be due to differences in billing, in which one division requires detailed payment information to be submitted with each order, whereas another division allows its business customers to purchase by entering the customer’s purchase order number.

The combination of different information in an order, with different payment regimes for different sites, makes it extremely difficult to allow a single order to be processed that contains items from different divisions. However, the designers might propose a change to the requirements to make them easier to implement. They could, for example, suggest to create an additional site for multisite search. This site would present all products of all divisions, in what seems like a single catalog, with the ability by customers to search through the entire catalog. On this new site, customers would create shopping carts, which would automatically be created with the divisions responsible for the selected products. Customers would see all their shopping carts, but they would have to submit each division’s shopping cart separately, in accordance with the relevant checkout rules, as shown in Figure 11.8.

Figure 11.8. Search-only site for a combined catalog and division-specific order sites

This proposal does not quite implement the requirement as stated by the business; however, it does make a step toward addressing the fundamental problem of bringing all the company’s products together into a single portal. From the customers’ point of view, they now have a single profile to maintain; they see all the products in one site; and the only slight inconvenience is that they have to submit more orders than they would like.

With some additional work, it might even be possible to allow customers to view all the orders in the combined site, by automatically querying all the division specific sites and bringing the information together for the customers’ convenience. This way, to the customer it would seem as though all the information they need is available on a single portal.

Such a suggestion can save a great deal of implementation effort, while being satisfactory to the business. Reforming the divisions to have compatible order processes is a daunting task that would take years and whose success is not guaranteed. However, with this approach, the divisions can maintain their individual order processes while still allowing for what is seen by the customer as a single point of contact to the company’s products.

Another important skill from the architecture team is to give early alerts to project management when the project is technically infeasible so that scope or plan change can be attempted before disaster looms.

A project might be infeasible because the schedule is too tight and it is unlikely to be completed on time or because the requirements are too unclear or too complex.

Project managers usually know if the schedule cannot be met because they are responsible to track the delivery of each line item, and schedule check points to determine whether the project is running on time. However, project management has no way to know if requirements or the designs are so complex that the development team cannot implement them. Only the senior technical leaders, with extensive experience in both design and development, have the ability to see that the overall team is struggling when implementing the designs.

This is particularly dangerous when development is outsourced to an external organization or offshore. For example, sometimes an offshore development team might misinterpret the requirements simply because they do not understand the language well. In the worst cases, to claim a reward, the external team might even claim that a work item is successfully completed, although in reality the requirement has not been implemented. In such cases, nobody might realize that the implementation is wrong or incomplete until the error is discovered during the system test.

Such misunderstandings are generally indicative of either fundamental incompetence or indifference by the development team. Corrective action can range from getting new, more experienced developers on the team, to changing the development team, or requesting the design to be simplified. However, only technical leaders, in their regular design reviews and other regular interactions with developers, can sense whether such a problem is brewing up.

This issue is hard to talk about, but if the senior technical leaders do not bring it up to the attention of project management, the problems will be found much later in the cycle when they will be impossible to fix.

You can expect that the development of a new commerce platform requires the involvement of a large number of developers, probably divided into multiple teams. In such an environment, the overall development must be closely monitored and governed by the overall architecture that is established early in the development cycle.

Frequently, the designers within each team have their own ideas that they would like to push forward. Usually these designers are all talented professionals, and in their mind they are trying to do their best for the success of the project, so certainly the technical leaders of the project would be well advised to listen to such proposals.

However, at the same time as giving everyone an opportunity to innovate and to improve, the architects must ensure that all contributors to the project follow the same architectural blueprint, and that the efforts of all the various teams converge to a single system that works as a whole. The central architects who prepare the overall architecture must ensure that they control the development processes so that any new ideas are implemented only if they are reviewed and approved.

The following is an example of such discord where a design decision made without regard for the overall architecture can ruin the project.

We see in this example that although the designers of order management mean well, it is important that their ideas are not implemented unless they are reviewed and approved by the architects. Part of the job of architectural leadership is to constantly monitor the activities and the ideas coming from the various teams.

The technical leaders must be strong enough to disallow inappropriate ideas, even if they seem wonderful to the designers who propose them. In the example of message mapping, it is possible that the order management designers can become quite frustrated and can push hard to let them implement their proprietary message mapping. And they do have a good case—if they do not do that, the delays due to the message mapping system can cause the entire project to be late!

Only strong and respected architectural leaders can withstand pressure from designers, and, if necessary, bring up the issue to project management to resolve the situation in the correct manner. In this case, delivering the project on time might seem like a worthy goal, but the resultant cost of dealing with defects and modifications in proprietary software can be so large that it is better to suffer a delay.

We have seen that strong architectural skills are essential to the success of a project to create a single company infrastructure. The experience that management should look for in these architectural leaders should, therefore, not be limited to technical ability but must include understanding of the business. Ideally, these technical leaders should have experience working with multiple divisions of the company and have familiarity with many business requirements across the company.

In addition, technical leaders must have demonstrated creativity in their approach to requirements. They must see the bigger picture behind the requirements and build a platform for the entire company, rather simply implement each requirement as if it exists by itself.

The technical leaders must ensure designs avoid excessive complexity, and developers are able to clearly understand what must be done. They must also ensure that any new design ideas and suggestions coming from the development teams are consistent with the overall architecture.

Finally, it does fall upon the shoulders of the technical leaders to evaluate the technical ability of the implementation team and to raise personnel issues when the ability is insufficient.

A common pitfall that bogs down commerce infrastructure projects is the appearance of dozens or even hundreds of various parties, all of whom want to give input into the requirements. Realistically, in a large company, consulting all interested parties is difficult, and certainly implementing everyone’s suggestion is impossible. On the other hand, it is important to involve enough key individuals that the resulting commerce platform can actually fulfill the company’s needs.

Everyone knows that large committees with more than ten members tend to work slowly at best, and ineffectively at worst. For this reason, most national parliaments have a long-established practice of assigning all serious preparation work to committees and subcommittees, while the main body meets to ensure everyone has a chance to give some input and to vote. The same applies to technical and project-level decision making—it is not advisable to attempt to air out each decision with the entire company; rather, decisions must be made by small groups of people, based on their experience, and with necessary consultation from the interested parties.

In this example, the failure seems to be on two levels. The first is that the company started commerce platform projects without first establishing its purpose or the major priorities. Although they clearly understood the benefits of a common platform, they rushed too much and started development prematurely.

The second failure is the attempt to determine the priorities in a large companywide meeting. This approach is fundamentally incorrect and can only lead to endless, boring discussions that lead nowhere. A large meeting like the one this company held can be useful to announce the new common strategy and to promote awareness of the effort to create the new commerce platform. It can also be used to field some questions that arise and even generate high-level ideas. However, this is not the way to plan the project or to collect requirements.

We suggest that it is much more effective to appoint a small team, hopefully having no more than five or six people, to guide the commerce project. This team would consist of the chief technical leader, the project leader, a business analyst familiar with the business, and two or three other influential and knowledgeable people with technical and business perspectives who are all employed full time with the commerce project.

It is typically impossible in a large company for a single person to understand in detail all the requirements for the company’s commerce platform. However, the members of this team can understand the areas of business that need to be involved and the key requirements, at least at a high level. The job of this guiding team is to propose and to pursue a clear and coherent strategy for building the shared commerce platform. Although all team members have their own responsibilities, the team should meet regularly and make the key decisions necessary for the success of the project.

These key decisions include the overall approach of the commerce strategy, such as the selection of necessary vendors or outsourcing partners. The team would decide which sites need to be built first and what key capabilities are necessary for each phase. The team could potentially reject some requirements and accept others. In some cases, the team might decide that some of the company’s business processes fundamentally inhibit the advancement of the commerce project and would start the effort to change these processes.

Although the team needs to be aware of the overall status of the project, this guiding team is not responsible for tracking the status of individual line items. Its primary responsibility is to consider major issues and to make timely decisions on key questions that arise.

With this approach, members of the guiding team can collect information from other divisions as they see fit and initiate numerous discussions with both lines of business and IT departments. In many cases, less significant discussions and detailed requirement investigations can be delegated to the relevant teams and subject matter experts. However, the key project-level decisions, which affect the health of the entire project, must be made by this small team.

An important part of delivering a commerce platform is to ensure that the platform and its capabilities are reviewed with the lines of business that will be using it. To this end, one multinational equipment manufacturer conducts a review of business processes that are to be provided by each new release of their commerce platform. As soon as the project’s goals and key requirements are settled, and the design is mostly understood, they bring together representatives from those lines of business that would be involved in using the platform and discuss, step by step, the business processes that would be followed. This leads to a rapid understanding of the missing features in the new sites or their administration. It also creates an opportunity for the lines of business to understand the new platform and how their sites would operate.

One disadvantage of this process review is that typically it would involve dozens of people from different lines of business. Most people are interested only in their small parts of the overall process, and are simply bored when the rest is being discussed.

It is hard to avoid this boredom, however, and in this kind of a meeting, it is not a serious problem. Whether this review is done by teleconference or by bringing everyone into a conference room, it is easy for the review meeting moderator to keep track of the progress of discussion and call to the attention of those people whose input is necessary for any specific portion of the process being discussed.

The pitfall with the approach of using small decision teams is that the lines of business might feel alienated or complain that they are kept out of the decision-making process. And they would be right—that is exactly the intent! However, this complaint would only arise if they feel that their input is either not sought after or is ignored. It is therefore important to ensure that consultations with lines of business and with IT departments do take place and that their requirements are understood.

It is also important that the decision-making process is clear to all the players involved. This way, if a conflict or dispute arises, there will be a well-understood process to review the issue and to resolve it. Even if the proposal is rejected, or the complaint is dismissed, at least each player will know that they were heard.

Bottlenecks occur when too many decisions are concentrated in the hands of only one key person, or a small number of people, who cannot cope with the volume of reviews and decisions that need to be made. Concentration of decisions in the hands of too few people causes work to be delayed because the implementers are forced to wait for decisions to be made. Particularly if the key decision maker is away, the entire project might need to wait because of a lack of competent replacement.

For example, it is not a good idea to make one chief architect responsible for reviewing and approving all designs; this task is impossible for one person to accomplish and would only distract the architect from dealing with the major technical issues that she must focus on. Similarly, it would be unreasonable to expect the chief project manager to single-handedly track the status of all line items and to approve the adoption of all requirements.

On the other hand, if decisions are distributed to a large group of managers and designers, overall control of the project will be lost. No matter how competent each person is, without central direction, inevitably the project will run out of control due to incompatible decisions being made by different people who are not consulting with each other, and who have different goals and agendas. We call this situation decision sprawl—where a multitude of decisions are made, and as a result the overall project turns into an incongruous agglomeration of efforts by many teams. Chances are that such a project cannot produce anything effective that even one company division could use, let alone a shared platform for the entire company.

Clearly, there is a need for a balance, where on the one hand decisions are centrally coordinated, and on the other hand decisions are made quickly.

There is no magic solution to achieve this balance, but the suggestion of having a central guiding committee would help. When the key decisions are in the hands of such a committee, the members can fill in for each other when some participants are absent. Furthermore, if some committee members are overloaded, they can delegate work to other members, or if necessary they can bring additional members to help with the workload.

It is a good idea to create a process where each major decision that is taken is recorded, along with possible alternatives that were discussed and the people who were involved in the decision. If any problem later arises due to the decision, this database of past decisions would help sort out how the problem started and what considerations were taken into account.

We must emphasize that the purpose of this database should not be to identify who is at fault for bad decisions. Rather, this process is useful to help correct problems that arise in the future. With this decision database, if later it is discovered that a past decision was incorrect and must be reconsidered, the team would not have to rediscover all the other issues and rationales that were already thought about. The past deliberation would be available, and the alternatives already proposed can be discussed again. As a result, hopefully the new decision on the subject will not ignore any issues and, therefore, will be better than the original decision.

At the same time, if too many changes are required during the life of the project, management can use the database to help understand what went wrong and why many decisions made in the past are changed. This decision database can serve as an invaluable tool in the post-mortem process after the project is completed so that future releases of the commerce platform can learn from the accumulated experience, and hopefully improve on the decision-making process.