Why Should I Model My Business?
There are a number of reasons why you should model your business. These range from high-level business planning to the maintenance of operational IT systems. Let's examine just a few. Most businesses have a mission statement. If they don't, they at least have a company vision, whether it is written formally or not. How do you know if your company's systems are properly structured to deliver that vision? What do you do when the markets change, requiring your business to change? What systems need to change? How does that change impact the other systems in your enterprise?
Some business leaders take the “Blues Brothers” approach to achieving their mission. For those of you who haven't seen The Blues Brothers movie, here is a short summary. The Blues Brothers had a clear mission, but that was about all they had. They had only a half-baked plan, which drove them to improvise all along the way, depending on heroic intervention by many people to keep things on track throughout the process, wreaking havoc and destruction on the people and places they encountered, running afoul of the law, and landing in jail. They eventually achieved their mission, but at a very high cost. Great comedy, poor career choice.
You cannot effectively achieve your mission or change it without understanding where you are, where you want to go, and what you need to do to get there. Let's say that you want to develop a distinctive business competence, such as being the low-cost alternative, being the high-quality supplier, being the fastest competitor, or being the top service provider. Where would you look in your business to effect the changes that will bring you to that goal?
All these can be addressed with a good model of your business operations. Without that, you are simply relying on the memories of individual employees for all the detailed information required to build such a model. You really have a problem if some of those employees leave the company. Even if you have all the right people in the same room, you cannot effectively perform an analysis of your business and all the required changes in your collective heads. In addition, each person has a particular context and viewpoint, which are rarely articulated clearly enough for all the others to fully understand. A visual model is crucial for providing a common baseline from which you can move forward.
Now, you must use your judgment and not take this to the extreme either. You need to document this information in sufficient detail to ensure that everyone interprets it the correct way without going overboard.
 | I was working with a company on a task to assist the business people in building a three-year plan. The idea was to understand how they wanted to reorganize their division to meet changing customer needs, establish new business initiatives, and prepare a funding request to implement the changes. A team of a dozen or so people was assembled: vice presidents, division heads, senior staff, and a few senior IT people. Others were called in as needed. We met frequently, trying to hash out this three-year plan using a reputable structured methodology. We focused on the business planning stages of the methodology for the purpose of designing the new business structure and operation. The meetings went on for weeks. The business people talked, the methodologist facilitated, the scribe captured volumes of information, and nothing was getting accomplished. One step forward, two steps back was the mode of operation. With deadlines looming, one of the team members pulled me aside and said, “You know that UML stuff. Do you think you can do anything with that to help here?” So, I took the business VP and his two assistants into a room and started talking to them about their business. I did not try to teach them the UML, but as they were talking, I was at a flipchart, drawing business use case diagrams (more on these later in this chapter). Seeing these diagrams caused a flurry of detailed discussion about their business and about the other divisions, other businesses, government agencies, and customers it interacted with. We very quickly found the root cause of the lack of progress—these three senior business people, whose job was to run this division, did not agree on how their division operated. This is a problem that we see far too often. These business folks were very smart and successful in running the division. However, nobody had the correct overall picture of how it all came together. Using use case diagrams, we completed the task in three days, whereas we had made little progress in the weeks we lost with the earlier approach. |
|
 | You must understand your business as it exists today before making changes. You must understand your business as you want it to be in the future so that you know where you are going. No one person fully understands, nor can keep in his or her head, all the aspects of a business that is of significant size. Do not overwhelm business people with technical terminology or tools. That's the job of the facilitator (modeler) to understand those things. Business folks run the business; modelers model. A visual model of your business, even a very simple one, will provide the “point-of-focus” needed to discuss and resolve business issues.
|
|
Modeling is useful not only in planning future business operations, as in the previous example. We often have to deal with the existing systems that run our businesses as we develop new systems. The integration of “legacy” systems in our plans is a task we all must eventually deal with. However, these legacy systems are usually a mystery to all but a few remaining people in the company. Effectively addressing existing systems requires more than just knowing what services that system provides to your business. There is also the need to understand that existing system's details. The passing of this knowledge along to the people who inherit these systems is critical to the continuity of operations so that they can upgrade or maintain them. But how often is this done? Also, whatever system documentation exists is typically out of date. So, this knowledge transfer is usually done at the “physical” level, by passing the source code to the next programmer tasked to maintain the software. Eventually, the code may be understood in this manner, but the business function this system supports might be more obscure. Even in the best of situations, this is a costly and ineffective approach. Having a model of the existing system in a common, understandable language is a tremendous aid.
 | When a senior programmer moves on to bigger and better things, it's always a challenge for her replacement to inherit, learn, and support their software. But what about when the user of that software moves on, too? This happened between system deliveries as part of a reorganization that occurred in my software development organization. I inherited a critical piece of software That had no documentation. Whose source code and data files were missing. Whose place in the overall business architecture was understood by only one person (the programmer who was leaving). Whose users did not understand the business or the technical concepts of how it was to operate.
I'm sure many of you have been there, too. How could this be a “critical” piece of software if it was left in this state? When it was written, it never was part of the official contract with their customer. It was built “off the books” (without documentation or configuration management) by a programmer who needed to solve a particular shortcoming of the system design. Specifically, in this particular system, there was a possibility that the data being presented to the user was inaccurate. If this inaccurate data was acted upon, a catastrophic failure could result. This software detected those errors and reported them so these problems could be fixed prior to the subsystem going “live.” This software saved thousands of hours of analysis that would have to have been done manually for every release of this system. (This situation happens often, particularly when dealing with software that is not part of daily operations, such as software that performs some form of testing, configuration, reporting, or initialization.) I was the engineer that inherited this problem. Finding all the pieces of this software took weeks. Understanding its operation took a few more weeks. But really understanding the design and the original concepts behind its operation took months. For me personally, this was a great challenge. However, the organization could have used my time solving other problems. A model of not just the software but also of the enterprise architecture would have reduced this ramp up cost and time dramatically. But that was only one level of the problem. The new users of this software didn't understand the concepts behind its use. So, what did they do? They constantly wrote defects (i.e., error reports) against this application that were not defects—that's the way the software was supposed to operate, but they did not understand. I spent a great deal of time constantly explaining to management, who kept seeing high numbers on defect reports, that these were not real defects. More lost time, more cost. But this saga continues. We will return to this example in a later chapter. |
|
 | Modeling your business and its legacy applications will help minimize the costs and impact on productivity when software is transitioned to new staff members. A clear model of how your systems are to be used operationally will reduce the learning curve of new users. This will also help avoid unnecessary maintenance costs due to “pilot error” or misunderstanding. Configuration control of ALL software that performs key functions is imperative. When you are creating software for an external customer, put all software that you are responsible for providing in the contract.
|
|
