The Same Big Things
The techno-clairvoyants have been strangely quiet of late... so I am left on my own to predict what "The Next Big Thing" is going to be. In the absence of prophetic visions, I think we'll have to refocus on the needs our old faithful source of income: Business.
- 1957: FORTRAN (FORmula TRANslation)
- 1958: ALGOL (ALGOrithmic Language)
- 1959: COBOL (COmmon Business Oriented Language)
FORTRAN and COBOL were developed for end-users, people who needed to use computers to accomplish a task (FORTRAN for Scientists and Engineers, COBOL for Business people). ALGOL was developed for programmers, people who needed to build the operating systems and networks that executed FORTRAN and COBOL programs.
Computing has come a long way since the 1950s, but the constituencies acknowledged by those "2nd Generation" languages are still important to remember: The needs of people who use computers to accomplish a task are different then the needs of people who build the infrastructure.
The 3rd generation languages like Java are far richer then their predecessors, leading many of us to believe that we don't need distinct languages for users and builders any more. I suspect that belief may have caused confusion for the "builders" and unintended complexity for the "users".
SOA is a good case in point. I've heard "builders" say that SOA stands for "Same Old Architecture", meaning that there's nothing new here; SOA is just a new buzzword for marketing types.
From the "builders" perspective, this is partially kind-of sort-of true, but from the "users" perspective nothing could be further from the truth.
SOA is a architectural style that is tailored for executing Business Processes. I'm sure that the "Service" focus of the acronym is due the the suitability of Web Services as building blocks, but the whole point is to make it easier to automate Inter and Intra Enterprise Business Processes (BPOA would be a much more descriptive acronym).
"Users" (in this case corporate developers) need much different tools for taking advantage of SOA then the "Builders" who are developing the infrastructure for SOA. SOA "users" need tools geared towards defining and debugging Business Processes... and this entails much more then simply defining and processing Business Forms.
A Business Process definition (according to the WfMC) "consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc.â€
One of the drawbacks with most existing J2EE applications is the inability to extract the Business Process and Business Rules from the running application.
The Business aspects are lost in the sea of details that make up the run-time environment. This is a huge problem for businesses; a simple change to a business process can be extremely expensive to implement.
I think that one "Big Thing" that we need is to put the "P" in COBOL (figuratively speaking): We need a COmmon Business Process Oriented Language.
We need to make a clean break between the code that implements the Business Processes and Business Rules and the underlying infrastructure. The BP infrastructure will still be written in languages like Java, but the Processes and Rules will be written in Business Oriented Languages by corporate developers.
The Business Oriented Language must be rich enough to describe processes that involve multiple business partners, some of whom may change as the process executes.
The Business Oriented Infrastructure must be rich enough to track each process as it executes across multiple platforms (JVMs, etc.), and provide the feedback that businesses need to tune their operations. Businesses will also demand simulators to quickly answer the question:
"What would happen if I made this change to my process?"
The infrastructure that will "run" Business Processes won't be implemented in a single language on a single platform. Business Processes span multiple Business Partners; heterogenous platforms are going to be a fact of life. Many of the building blocks for this infrastructure are already in place, but the whole enchilada is far from finished.
Gregor Hohpe's ramblings are as good a place as any to see just how far we are from finishing the infrastructure that we will need. For example, today's BPM tools (like those from Oracle and BEA) almost all require a central "controller" for the Business Process, but this just doesn't match reality. Business Processes are a lot like conversations, you make an inquiry and expect a response... but that might spin off a whole new thread that you now nothing about. Building an infrastructure that can support complex processes is a daunting task.
Searching for the perfect Business Process Language is sort of like the searching for the Holy Grail. BPEL is a good start, but it still doesn't handle some common scenarios.... which is why BPMI.org and others are already working on BPXL. The Workflow Management Coalition's Extensible Process Description Language (XPDL) or UML Activity Diagrams might be a better starting point... but the jury is still out.
Bruce Silver's article "Agile To The Bone" is a very good summary of what's up in standards land.
Update: 14Mar05 - Dick Wall has written a good article on Java Studio Creator about the advantages of having different tools for developing UIs and business logic. This ties in well with the concept of having different tools for developing Business Processes and the underlying Services.
(Cross posted at The Thoughtful Programmer)