Modeling "As-is" versus "To-Be"
There are two terms we commonly use to designate the current and future state of a system. We call the current state of a system the "as is" system because that's as it is currently. The future system or process is known as the "to be" solution or process.
When we start to model either a business process, a web flow, a data flow, or really any other part of our system, it would seem that modeling the "to be" model matters more than the "as is" model. You could argue that this is true since we are going to spend majority of a time design, build, testing, and deploying the "to be" system.
That being said, it's also can be very valuable to model out the "as is" state of a process or system before you move on to thinking about solutions. Why is that? Well, there are a couple reasons:
- It forces you to get very intimate with the current state of design that exists so you know fully know how the system is used, the business rules, and perhaps what limitations/constraints exist in the system or process. Here's an analogy. If you were to add on square footage to your house, an architect will start with the current floor plan and survey, to know how the "as is" house is situated and better be able to see how the expansion will fit into the "to be" solution.
- It fills in the missing documentation that was never done before. Sometimes we have to be willing to write down what others have not wanted to write down. Having an "as is" model of the system or process could enlighten you (and your client) to process inefficiencies or perhaps situations where people use overlapping words in differing ways.
Once the complexities are pointed out, and sometimes only after they have, can we begin to get people focused on the future. "Sometimes, we have to take the time to consider where we are before we can begin to understand where we are going." - Nick Malik (Microsoft Developer)