Enterprise Architecture -- Lessons From the Laundry Room

I was recently involved in an enterprise laundry management (ELM) project to automate the wash-to-dry value chain of the Cook household. The legacy systems were inefficient, maintenance was costly, and the users were very dissatisfied. Sponsors were identified, a business case was made, funding was approved, and the project was under way.

The legacy system portfolio consisted of a 20-year-old washer and a 10-year-old dryer. The two biggest issues identified by the ELM project team were that the users had to use multiple systems to get their job done and that the laundry had to be moved using antiquated batch interfaces.

A simple, elegant solution quickly emerged: a tightly integrated application for the entire laundry management value chain. After all, the exact same user community did the washing and drying, and the same redundant clothing was used in the end-to-end business process. The two legacy systems even kind of looked alike, though one was avocado and the other autumn gold (both are no longer supported by the manufacturer).

Eureka! The new system would have tightly coupled washing and drying functionality and a single source of clothing. In addition, the application would be designed as a set of washing and drying services that could be invoked in real time for each piece of laundry.

As detailed use cases were developed, the project team discovered that it was possible for certain undergarment transactions to exit the entire business process lickety-split, maybe in less than three minutes. The entire team was energized, and articles were written about the anticipated gains in efficiency and business process throughput.

However, as in any project, issues began to surface. First, the business people began to get nervous. The organization might not be able to handle the change in business process, especially the speed at which underwear would individually exit the unit in real time. Then the solution architect chimed in. There seemed to be some serious design issues with the fundamental tight coupling of "wet" and "dry."

The project dragged on and slipped behind schedule. Project scope was reduced to "part wet" and "part dry" to get it back on schedule. Then there were some significant issues with getting the monolith down the stairs and through the laundry room door for testing, but in the end, the system worked and was ready for full implementation.

A project status review had the following executive summary: The clothes weren't very clean, and they weren't very dry, but they were exiting the dryer at top speed, one piece at a time.

Taking It Beyond the Laundry Room

There are two very important enterprise architecture lessons hidden in this tongue-in-cheek story:

  1. Not every system in the enterprise, even those that are used by the same set of users, should be tightly integrated. The boundaries between enterprise-level business processes and their supporting applications are not arbitrary. Find those boundaries using common sense, industry best practices and lessons learned, and back your findings up with enterprise-level business process and data modeling. You may find in existing, well-engineered applications -- yours or those that belong to software suppliers -- a good indication of where you should loosely couple your business processes and enterprise applications.

    A very useful enterprise architecture principle is to design systems around natural boundaries of business process and data, tightly coupling within, and loosely coupling between. My belief is that standards will eventually emerge around where these boundaries are for enterprise-level applications or modules of commercially available enterprise suites. They are similar between organizations. If the boundaries become standardized, less care will have to be taken about what the various software suppliers, including those in your enterprise, do within their own version of the washer or dryer.

  2. Batch does not equal bad. It depends on the business process. Some business processes are batch processes for very good reasons. Batching transactions between naturally bounded enterprise applications may be a very good approach in some cases. Your interface reference models or standards, part of your enterprise architecture deliverables, should reflect batching transactions as an acceptable approach.

Back to the Drawing Board

Let's take another cut at our washer and dryer story. This time, the project team completed the enterprise process and data modeling and discovered there was a significant functional difference between "wet" and "dry." A quick industry scan confirmed that everyone else pretty much thought the same way. So a decision was made to keep the two systems loosely coupled. After looking at the requirements of the interface, another decision was made that, in this case, the loose coupling would be most efficient using a batch approach. (Note: Not all loose-coupling approaches need to batch transactions.)

In this new version of the story, we could have reduced the scope of the project to just a washer or a dryer. However we had the money to cover the original scope, so two smaller project teams worked mostly in parallel on greatly improving the individual processes of washing and drying. The washer was much more efficient in using water by delivering new pump and extraction technologies, and the dryer was much more efficient in using power through new heating element approaches. Although the interface was batch, we still greatly improved the approach. Both systems are raised on platforms so the users don't have to lean down to make the interchange.

There were still some opportunities for reuse across these loosely coupled enterprise applications. The platforms already mentioned are a good example. There are also nice electronic tunes when cycles are done instead of a loud buzz that sounds like time-out at the Key Arena.

A note to the wary: Yes, the users are still using two different systems, and, yes, the users will have to eventually use two differently styled machines when the dryer inevitably wears out faster than the washer. We could have implemented an enterprise laundry portal (i.e., have a person come in to do the washing and drying so the users wouldn't know there are two systems), but as yet, the budget won't allow it.

A note to the wise: I'll be able to replace the dryer much faster than the monolithic combination that would have taken forever to build and, more importantly, forever to replace, especially if I integrate a stove and oven over the years.

Check out the recently advertised refrigerators, freezers and wine coolers that function completely independently. Why? "Unprecedented flexibility." Loosely coupling your enterprise applications will give you unprecedented flexibility and is also what your executives are searching for.

I have to go now. The washer is singing my tune.

Melissa Cook is a consultant and the author of Building Enterprise Information Architectures, published by Prentice-Hall. Previously, she was at Hewlett-Packard for 20 years. She can be reached at macookcorp@aol.com

Enterprise mobility 2018: UEM is the next step
  
Shop Tech Products at Amazon