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.
Comments
Anonymous
July 30, 2007
The comment has been removedAnonymous
July 30, 2007
You made your argument for this but did not give a solution or example of what the solution might be for a "Business Process Developer". What is your proposal for this?Anonymous
July 30, 2007
I am old enough to know that we've been down this road many times before (CASE, anyone?). You need to really think about the following statement: If the code that comes out doesn't meet their needs, the business process developer knows it the moment they run their code. I am confronted every single day with abundant evidence that this is simply not the case. In fact, the opposite is more often true: Somebody discovers six months too late that the business process is fundamentally broken by a minor change to the workflow. That's not a criticism of the workflow developer or report writer or business process developer. It is a mistake to assume that the connections between services can be rearranged, repurposed, and reused without a deep understanding of the services themselves. We software developers like to think that we can make systems that mimic hardware (standard bus architecture, etc.). Instead, our systems are much more like biological systems where even interconnections that use the same 'technology' vary tremendously (e.g. your brain and your gut both are both connected to your blood stream for the same reason, but I wouldn't suggest trying to swap them around).Anonymous
July 30, 2007
Nick Sounds like you are trying to describe "codeless" development, which is a dream that Ismael Ghalimi (http://itredux.com/blog/) pursues, via his BPMS Intalio (http://www.intalio.com/). It's a goal I've pursued in the past, just like JohnCJ above, and SO FAR, my experience is the same. The whole service-based framework idea suggests that it is possible, but I also doubt that services can just be strung together successfully unless you have a pretty good understanding of the operation of said services. But I am watching Ismael and Intalio closely ....Anonymous
July 31, 2007
Another excellent article. I have written a first attempt at something like this (based on the BPMN notation) that allows process mappers to join services together. It is not as easy to use as it needs to be (especially around data folws). The main problem has been getting people to use it for creating executable processes not just maps. Afte reading your article I can see that maybe I should be targeting business users not developers.Anonymous
July 31, 2007
Thanks for the article. One of reasons to why the code requires maintenance is the iterative nature of the development process. There is no so much pure innovation out there. We simply want to deliver the functionality like X but with our bits on top (the added value)... I like to think that BPM or same level abstraction will help integrating business users input more rapidly. And it is form of a code, after all....Anonymous
July 31, 2007
@KBac, There is still an equal share of "art" in the science of software maintenance. We ask the question: when does it become cheaper to change what we have than it is to write something new? The point of my post: our tools should be SO GOOD (still a fantasy) that the decision to modify rather than write new code literally goes away. There should be no difference. This means that the process developer can understand what is going on quickly, can modify the process or create a new one with the same level of ease, and can verify and validate its correctness in an elegant and repeatable manner. Deployment shouldn't require a dual degree in neurology and electrical engineering. There's still a way to go.Anonymous
July 31, 2007
@JohnCJ I remember CASE tools. They were sold with lots of blaze and fury but they NEVER approached anything similar to what we can currently accomplish with reference implementations of BPEL and BPMN. Add workflow (BPEL4People) and we are coming very close to creating a paradigm that allows the composition layer to be completely independent of the services layer. And you are right in that most of our service developers are completely clueless about how to play in that space. I am working on a framework that would allow the creation of services that would work well in that world, where composition is not only possible, but practical. It is one thing to curse the darkness. It is another altogether to light a candle.Anonymous
July 31, 2007
The comment has been removedAnonymous
July 31, 2007
The comment has been removedAnonymous
July 31, 2007
The comment has been removedAnonymous
August 02, 2007
Nick, I like what you're saying, but aligning mashups with business process is too close to what IT does with BPM/BPEL, etc. The real value in mashups is to support the notion of ad-hoc integration. Ad-hoc integration is user focused, situational and should be share-able. It is also very small. BPEL, BPM, etc is very large and belongs in IT. Business process people typically work on the big business processes. Mashups are better suited for helping the business user get out of having to integrate everything using Excel. For a good mashup overview, check out Deepak Alur's blog: http://blogs.jackbe.com/2007/07/defining-mashups.htmlAnonymous
August 02, 2007
@John, Do you think the business cannot have a PM that manages a BPEL developer who combines services together? I know business units that grow their own IT department! They can certainly do a BPEL developer. No need for that to be inside IT. As for pure (thin) mashup, nothing I've said opposes that paradigm... but not everything can be done as a mashup. We can have BOTH. --- NickAnonymous
August 03, 2007
Hi Nick, I agree that business can have a PM who manages BPEL development. I was really trying to make the distinction between heavy weight BPEL/BPM and lightweight mashups. Developers create BPEL and users create mashups. -jcAnonymous
August 06, 2007
Hi John, I see where we went astray. I said "Free code is mashup code." I believe that mashup code has come as close as anyone has come to the concept of free code. I meant it as an example of what "free code" really is. Our current tools are not there. Our tools make it so complicated to create a business process diagram that only a developer can do it, and then to decorate that diagram with service interfaces and endpoints and channels, only a developer can UNDERSTAND it. We need to fix this. Our current tools MUST improve if we are to help empower BPM transformation. --- NickAnonymous
August 10, 2007
The comment has been removedAnonymous
August 10, 2007
The comment has been removedAnonymous
August 11, 2007
The comment has been removedAnonymous
August 12, 2007
@Charlie, You are clearly an intelligent person, Charlie, and I think we have a lot in common. I am sure that if we were to sit together and discuss ideas for a few minutes, we'd find that we have a lot more in common than different. When someone develops a new appliance, they are empowered by the standards, not limited by them, but just because an appliance has a power plug, that doesn't mean it can ONLY interact with the power network. My computer is an appliance that also interacts with other devices on the Internet. My television interacts with other devices on the Cable TV network and the internet. My clock radio interacts (read only) with other devices on the radio broadcast network. My central air conditioner interacts with the rooms of my house over the duct network. They all draw electricity. Every network has their standards. We are not limited to one network. This allows novel combinations that do NOT affect the design of the electrical network. I would posit that it is fairly simple to create some basic "networks" of messaging that allow systems to interact in predefined ways, and allow the composition of business processes by process developers in an unmaintainable (free code) manner.Anonymous
August 29, 2007
Mike Walker wrote a great thought-provoking blog post on the implications SaaS has on Enterprise ArchitectureAnonymous
August 29, 2007
Mike Walker wrote a great thought-provoking blog post on the implications SaaS has on Enterprise ArchitectureAnonymous
August 29, 2007
Mike Walker wrote a great thought-provoking blog post on the implications SaaS has on Enterprise Architecture