Enterprise Applications vs. Workgroup Applications
Which is better, to create a comprehensive application that integrates an entire area of a business, or to solve a small problem with a quick and easy program? I think that in enterprise applications, to look at point solutions and not expand to an entire area of a business is difficult. But as you can see in nearly every business, there can be great value in small database applications that solve a single piece of a larger problem. Here are the pros and cons of each tactic, let me know if you agree.
Enterprise level, for this article, does not have to encompass an entire organization or enterprise. An application achieves enterprise level when it encompasses at least one major grouping of functions in a business. Most businesses have a few major areas of functionality that are loosely connected to one another. Inside those major areas are typically many smaller functions that are more closely coupled to accomplish the larger goal. All of the major areas of functionality make up the total organization.
As an example, let€™s look at a warehouse that is used to store finished goods of a manufacturer before delivery to a customer. The warehouse receives finished goods from the plant, holds goods, and then picks the order to send to the customer. The interfaces between the plant and the sales team are relatively small. With the plant, the interface is delivery of the product. With the sales team, it is to ship the order. Inside of those two tasks though, are dozens of smaller and much more highly related tasks. Someone picks up the new product from the loading doc, checks it for accuracy, maps where it should go, and records the location. They might need to reorganize their stock based on internal space needs. Eventually, they will need to decide which exact product should fill an order based on rules. They need to manage the flow of trucks, rails, shipping companies, or all of the above to get the product shipped. They may also need to check the product for damage while in storage and might have responsibility to load correctly.
The enterprise way of looking at this environment is to take each stakeholder in the warehouse from the interface with the plant, sales and shipping, and all the internal stakeholders and find out what is important to them. Then, create a model of the process that is required, and rules that must be followed, to maintain order in the whole complex system. Invariably, each stakeholder has a different and limited view of the entire model. The designer looks at all the individual “facets” to find the underlying model of the data and the workflow.
Communication is typically the most difficult and time consuming part of any process. A single person may put the product away, reorganize the warehouse, and then need that product many months later. There is a need to communicate the original locations and the changes over time in order to be efficient. Even more problematic, is the same scenario performed by more than a single person. The more tasks, the more different people doing them, the more important reliable persistent data becomes. If the model created, covers all the data that everyone needs in a way that is usable for all the parties, then the program adds to the efficiency level of individuals and the team. Because it covers all the facets it is less likely to be inconsistent and more apt to increase efficiency.
Businesses are highly complex systems. The behavior of one of the actors affects other actors performing different activities in ways that are not important to the original actor. “The other activities are not important to my tasks, my rules take priority” says the first actor. If my behavior negatively affects the others results, I may not know or care. An enterprise level program can decrease this negative effect by enforcing the enterprise rules, making the rule important to everyone. The system can also make it very easy for actors to follow the correct rule. The enterprise level application can model the human rules governing the process and validate them using the program even for areas outside of a specific person’s area of responsibility. This is where a high-level of benefit is obtained because all the extra work, extra talking, and extra conflict that people get into over these issues goes away. Workflow becomes smoother and efficiency is increased in ways that are hard to predict, but easy to see.
But there is another way to think about it. Sometimes, there simply is not the budget or the time to think through the entire process. Sometimes, if you don’t have a programming team you can trust, there is a risk that you will not get the results you expected because the team will not truly be able to model at the enterprise level. There are though, excellent results you can get from smaller, workgroup programs. These are applications that solve very specific task problems within a functional area. In the warehouse example, this might be a program at the gate, where the guard can check in a truck and the screen at the loading docs where the warehouse team is, can see who is at the gate waiting and how long. When a truck leaves a loading dock, the warehouse team can approve the next truck in line or can authorize another truck out of turn, if that would be the most efficient. The guard can always see the status at the loading dock and the loading dock can always see the status at the gate. This doesn’t take into account orders, where the product is, if the product exists, or a myriad of other details of the tasks in the warehouse, but it does solve a very specific problem and costs much less than the enterprise application.
Some think you can build a lot of workgroup applications and stick them together to make an enterprise application. Don’t be fooled; this is nearly 100% doomed to fail. The analogy would be building a bunch of single story houses and deciding to put them on top of each other to build a 10 story condo. It is conceivable that the pieces will fit together but the odd’s are strongly against it working. Even if it does, the probability is very, very high that the resulting Winchester Mystery House of code and data will be difficult to manage and be inefficient. The Winchester Mystery House was built by an eccentric who felt like she would die when the house was complete so she kept building even when it was illogical, creating walls over windows and staircases that led to nowhere. Like the Winchester Mystery House, the patched-together programs might perform some of the functions, but be confusing and likely to give you inconsistent results. You would soon want something more elegantly designed.
There are significant differences in how you develop for the enterprise vs. for a work group solution. Developing an enterprise application means merging many views and definitions to find the underlying model of the business. One persons view is, on the surface, likely to conflict in subtle and sometimes not so subtle ways from another persons. This functions in the every day work of a business because the parties are very context sensitive. Words that are used with different definitions in different tasks are used without confusion, mostly, by the organization because they all know the contexts. But when developing an enterprise version of the model, these conflicts must be resolved such that each person’s view gets translated to the others view with a free flow of information. This is why it is very unlikely that a series of work group applications will efficiently merge into an Enterprise Application.
A work group application, on the other hand, is used by people who are talking the same language or in the same scope so to speak. In this case, conflicts and missed communications are not likely and are much more easily resolved. So in the work group application, such as the application that the guard gate uses to communicate two ways with the loading dock, we can start with screen designs of what we want the communication to look like. These can then be used to create a model that will function in that context fairly easily, and the screen designs are familiar, so an operations person or business analyst can simply draw these designs with relative ease. Tools like Balsamiq make the process a bit easier for those of us who are not great at drawing and they also enforce, ever so slightly, a look and feel that can be created in code.
How far the work group application can be taken is dependent on many factors. There have been enterprise or near enterprise applications that have started as work group applications and grown successfully. But there is risk. You cannot know in advance how far the process will take you. You also cannot know in advance how well a group of work group applications are going to work together. What I can say from years of experience is that we have been called in numerous times when a work group app has hit it’s limit and there is nothing that can be done successfully or well, except start from scratch. Frequently, we have been called in when a less experienced programmer or company has started an enterprise level application with workgroup application skills. Again, the application will have hit its limits and the customer rarely understands that it is the programmers fault. The good news is that in those cases, where a work group app is simply outgrown, it is likely to be a great deal of help in building the specifications for the enterprise application. If that is understood, then it is easier to accept the rewrite. If you have an advantage to gain from the work group application in terms of direct return on investment that exceeds the cost quickly, 12 months or less usually, and it can help you understand the bigger issues, then work group applications make a lot of sense.
In summary, the workgroup application is a terrific solution to specific problems; it is weak when the limitations are not well understood. The enterprise application is more costly to start and requires more design and architecture but is more likely to bring higher and longer term value.
