Free Code - Getting IT out of the Applications business

There is one big thing we must do if we are to make IT align with business strategy, we need to get IT out of the role of interpreting the whims and desires of the business.  The good folks in IT are really bad at mind-reading.  As long as we are in the "mind-reading" business, we will never be given credit for what we do well: automation.

The answer: let the business folks write free code.  Not just any business folks.  We let Business Process Developers write free code.

What is free code?  Free code is unmaintainable code that wires together service calls in a way that is inexpensive to produce.  Free code is mashup code.  Bugs can be fixed, but we don't really maintain it.  If we want to change free code, we write it again.  It was so inexpensive to build that it costs less to rewrite than to modify in any non-trivial way.

Free code, in order to be truly free, needs to be generated from tools that are NOT coding tools.  In other words, software development environments are too rich for free code.  Why?  Because it is too tempting to build expensive code.   We need to differentiate, then, between the rich, highly designed, object oriented code that software developers produce, and the free code that business process developers will produce.

Note: I said that free code is unmaintainable.  Code is unmaintainable because it's complexity exceeds the ability of a developer to maintain it. Let's dig a little deeper.  Why do we need to maintain code?  Because code is expensive to write.  Therefore, it is currently cheaper to fix it than rewrite it.  On the other hand, what if code were cheap, or free?  What if it were cheaper to write it than maintain it? 

 Then we would never maintain it.  We'd write it from scratch every time. 

Sure, we can choose to write maintainable code.  We can use practices like patterns, object oriented development, and careful design principles.  On the other hand, we can give our business project managers an environment where they can describe their needs and code is simply expressed from those needs.  If the code that comes out doesn't meet their needs, the business process developer knows it the moment they run their code. 

What is the value of doing this?

1) Lower the cost of IT through reduced skill requirements.  The skill set of the Business Process Developer is different from that of a software developer.  Traditionally, we've sought folks with both skill sets to employ as software analysts.  This usually meant training someone.  What is wrong wit that?  Answer: We've created expensive specialists to overcome tool deficiencies.  Why not fix the tools?  Then we won't need the specialists that cost so darn much.

2) The speed of development goes up.  If the business process developer can change the process wiring readily, then the software developer can focus on making the needed updates to the services themselves.  This removes the coupling between process and code that slows down EVERY project in IT.   

3) Projects become more agile.  Since a business process developer can develop a mashup of services quickly, they can demonstrate that mashup very readily, directly to business stakeholders.  A change can be shown to the business folks quickly as well.  If the business needs change, or their understanding grows, and they need the services to do something more than they do, then this kind of agile process encourages rapid feedback to the developers who own the services themselves. 

4) Solution quality goes up.  Since we can focus our deep design team on developing the services that the business process developers consume, we can improve the quality of those services independently.  This allows for better measurement of quality and an increased focus on the key quality measures inside each service.  Reusability is a natural outcome of high quality services.

What does this mean for our tools:

We need to seperate business process modeling from software development and produce rich tools aimed at the needs of the BPM practitioner.  Those tools need to start and end with an understanding of business capabilities, tied through to business processes, and down to events and business documents against a common information model. 

We need our tools to reduce the leaky abstractions that we currently call 'services' by helping developers build services that are very simple to consume by the business process developers.  We need to capture these requirements and act on them through automated mechanisms built in to both the BPM environment and the IDE.

What does this mean for our processes:

The good folks in IT need to formally and officially take control of managing the common enterprise information model and the business event ontology.  If a business wants to change the data and event models, they need to work through a published process that allows and encourages consensus. 

The good folks in IT need to formally allow business process developers to easily develop, test, and deploy their processes.  Deployment is a problem because IT folks normally just 'fudge' their way through deployment processes.  If we are going to let business process folks to write code that we deploy, then it needs to be very simple to deploy that code.

Free code makes sense...  We need to align IT to business, and this is one very useful mechanism to do it.  It is time to stop getting in each other's hair.