Smaller apps, rosier future.

ERP be damned

Practically from the inception of computing has been the desire to make big omni-functional applications, systems that are everything to everyone. These take years to write, need massive crews to maintain them and never quite catch up with the users needs, even as expressed on day one. Worse, in many companies I have been in, the business units that are forced to use the monoliths have taken to only entering the data they need and entering faux data for everything else. Folk know that this might be bad, but who cares? all they want to do is get their job done and their data in place, devil be damned. Someone down the road that makes tactical decisions about some aspect of the company's business is now making reports on garbage data. The implications for justifications on decisions made with this data have to be suspect. In a large enough company, the pour souls making the decisions on these reports may have no means of confirming accuracy of the data. The system is maintained because people at the bottom are ignored, people at the top think they are getting real data and can make real decisions on it, and the IT group are too full of their own bullshit to bother attempting to implement something that might truly give the business a tool worth working with.

These big systems cost MONEY (often upwards of $10 million, some as much as $150million), frequently just to purchase the software. The cost does not include all the years of development and maintenance required to fix the mess from the day after the project is said to be installed and complete. Some very big consulting firms have become very rich because of these types of bottomless cost bucket systems.

Why don't they work?

Since we got ride of typing pools with 100's of secretarial slaves and rooms full of clerks scribbling with quill pens, we have repeatedly asked less people to do more. We have moved into an era where quite small departments are responsible for a much wider breadth of detail than before (the horizontal), or they are responsible for the complete development, and sale, of a single product (the vertical). This emphasis on less people doing more and more, and smaller functional groups, has meant that a homogenous solution to a business problem is less and less likely to work. The groups now do items that no one else in the company is doing, or doing it in a manner that no one else does.

When the computer analysts come in to determine what the new system should do, they are faced with either having to create a myriad different modules to handle all the needs or create one huge module that is supposed to have all needs encapsulated in it. As modules frequently increase licensing costs, there is generally a move away from the multi-module approach. The systems are then laid out on paper, some methodology (we hope) is applied to convert the requirements into functional needs that the programmers can understand. The process leads to time estimates and implementation. This implementation phase can take years to complete; many such projects have been going more than 4 years. This time lag between questions being asked and the solution being evidenced leads to a huge discrepancy in what is actually needed and what people are now doing.

Teams

Businesses have espoused the concept of teams for perhaps 40 years. The concept has been relatively well received; people feel empowered, the work they do is more representative of some final end point - a success, perhaps. The teams have diminished in size since the 1960's, when thousands of people in a single room were seen to be in a team (think Apollo Moon project), today team means a much smaller functional body, perhaps as few as 4 or 5 people, infrequently greater than 50 people. Over about 20 people in a team and it is hard to tell if all the people are working to the same end. Such small teams function aggressively. They are tasked with high productivity, short timelines and the possibility of rapidly changing process needs. These teams cannot function with 4 year old software, let along the 20 year old junk many large corporations still utilize.

Small is Great

Looking at how smaller teams gain software, how it is built, used and then terminated, we have to look at how the teams making the software fit into the Corporation, how they function and how they can be enabled to produce systems faster and more reliably. There has been much talk, and plenty of action, on the use of frameworks and patterns, these tools should have aspired to allow the creation of software of higher quality, more quickly. Unfortunately they have not worked well: frameworks have been terribly expensive to create, end up being useable only in very limited situations; patterns operating at too low a level involve too much intricate detail to allow developers to break out and produce software rapidly.

Committed to the small is beautiful concept dictates that IT has to become less efficient at the micro economic level to become more efficient at the corporate economic level. Structurally we have to look at how analysts and programmers can be committed to support teams, then how they can be used to produce software that meets a higher level corporate need for data.

The interaction of how a team is tasked to fulfill a perceived need, how that task is adjudged complete, and how the process works to refine the targets has to be understood before allowing us to develop software for the corporation. This understanding, I believe, leads to small incremental applications being developed that have some central focus, though their connection to the central need is tenuous (yet necessary). This need for independence, and at the same time a requirement to provide a central organization with the information to track progress allowing definition of how the future will be approached, is critically important. It mitigates against the monolithic applications of the past, it foresees many smaller applications many being cast out to die when their time is up - the users not doing that work in that way anymore - at the same time stressing that there be means to push data up to the corporate levels where teams tasked to divine the future are reviewing the past data. The data these corporate teams review has to be as accurate and believable as possible, hence the need for carefully defined, refined and pinpoint accurate applications that generate the data.