The Typical Organization
The typical enterprise application infrastructure looks like this over time.
The word platform is very overloaded. As mentioned in a previous blog, by itself it is pretty meaningless term. However, for WSO2 we have thought about what is a platform more systematically. As we built the distributed software platform up from the ground during the TIBCO days and WSO2 rebuilt them later we got a good understanding of the valuable components that organizations typically had to use to solve enterprise problems. The spaghetti architecture you see above is the result of years of building software in an ad-hoc way.
The messaging mantra
Over the last 30 years of building enterprise software one of the principal things we decided on was the notion of a “message” as a way to transmit information from one application to another. In the publish / subscribe paradigm it means that if I have some information I can publish that information and anyone who is authenticated and authorized and interested in that information should be able to get a copy of that message. If I am interested in information of a certain type then I should get those messages if they come from reputable authenticated and authorized applications and users. This approach which we at TIBCO promulgated become very prominent in the way people thought about designing some technology but not all. Many people simply subscribe to the idea that if I need to send information from process A to process B the cheapest fastest easiest way is the way to communicate from application A to B. A principal value of the platform 2.0 (distributed system platform) that has evolved over the years is to simplify dealing with messages and all the things you might want to do with messages.
The Dimensionality of an Enterprise Software Platform
We learned during these years that there were a number of dimensions to software development. Imagine the diagram below represents different axis in a multi-dimensional space of the problems that enterprises have to face in building applications.
Now imagine your typical enterprise application. It has elements of each of these axis in everything it does:
Axis 1) Long transactions versus short transactions
Sometimes a transaction can be concluded in a short period of time: Customer wants to buy X. Sometimes it’s a longer more complicated process.
The process of recording the fact that a customer wants to buy X is atomic and small. We developed the ESB to make specifying short duration transactions easy and even graphical. The overall process of completing the sale, stocking and delivering the product to a customer may be much more complex and long lived. This is called a business process and the tool we developed was a “business process engine.” to do that. Usually a BPE (or BPM business process manager, BPS business process server) consisted of implementing several steps that were shorter lived or involved human interaction. A BPM system and language as well as graphical tools to enable organizations to easily spell out these business processes was created similar to the mediation tools for ESB’s.
IMPORTANT LESSON: Using the right tool is critical
It doesn’t make sense to use a BPM system to do short duration transactions and it doesn’t make sense to do a long duration transaction in an ESB tool.
If you were to use an ESB to do very long lived transactions you would end up with a very fragile system as the components would not be designed to handle such long lived state and would potentially need a lot of coding and work to handle the failure scenarios that result. You would be stressing the components to the point they would have failures far more often. It would be difficult to make it work making the whole point of using the tool in the first place pointless. The same is true of all the components I will talk about here. The components are designed to handle that axis of enterprise complexity and remove most of the stumbling blocks to building them fast and reliably. However, if you use the tool to build what it isn’t designed for then you might be better not using the tool at all.
Axis 2) Stateful vs stateless Transactions
Some activities are stateless, meaning that the server can perform the transaction without having to know session information
A good example of stateless operations are typical google search queries. If the server and user are disconnected no information is lost that is critical to go forward with the next operation. Each query is treated independently and therefore any server in Googles farm of servers can process the query for you without having to worry if the next query you do is routed to a completely different server that had no prior knowledge of the previous query. Such transactions are wonderful and provide easy scalability. These transactions are ideal for the messaging architecture of ESB’s. Ebay(TM) for instance uses the WSO2 ESB to process and route transactions for everything you do via the web or in mobile applications, some 3 billion transactions/day and more on high traffic days.
When an operation a user performs becomes stateful then it is inherently more problematic. This requires use of more reliable components, i.e. Message Brokers, BPM engines, Application servers can keep the state. An example of this may be an application that depends on data and things you do to your screen, i.e. a computer game for instance. Numerous pieces of the Platform stack are designed to make this state management easier and to make recovery of state in the case of failure for one reason or another easier.
Axis 3) Fast changing rules vs more static fixed rules
Do the rules for the performing the transactions change frequently or have to be customized depending on many factors or are all the operations pretty static that change infrequently?
Some Enterprises have fairly fixed rules of business that change infrequently. These rules can be codified or parameterized easily and implemented as hard code in components straightforwardly. You simply place the current parameters for your decision making in a “safe” place that is consistent across your organization. A registry is a good place for such parameters. It maintains a state of the parameters and allows a general dispersal of the changes to the parameters in a controlled way to all applications that use them.
However, some organizations need more flexibility in their rules of operation than simply a set of parameters. They want to be able to amend the rules for specific customers or change the entire way the rules are decided or implemented for any number of reasons. You may not know in advance the kinds of rules your organization will want to put in place. Such flexibility has become more and more commonly required and Business Rules Engine (BRS) have evolved to support the easy specification of complex interacting business rules.
IMPORTANT LESSON: The point of all these components is that they systematize common enterprise functionality using best practices. If your development organization had to build a rule engine every time it wanted to implement a flexible rule somewhere it would take more time and would result in inconsistent capabilities. So having a general solution to the problem of handling stateful transactions, long business processes, short fast business transactions simplifies and makes higher quality results for enterprises.
Axis 4) Real time or Batch?
One of the first uses of the new Platform 2.0 message orientation was to track activity events and trigger other events. Such monitoring was called BAM. Using BAM you could calculate some statistics like number of transactions in certain time periods, uptime and other interesting KPI. Enterprise platform 2.0 evolved to allow something called Complex Event Processing which was a fancy name for being able to produce a real time result that depended on a sequence of previous events. It is realtime pattern recognition. This gave the capability of doing things like: “If you see this and then this and then this, then do this” in realtime. Databases generally couldn’t do such queries in realtime so you were left to build such recognition as an application. CEP made it much easier to create lots of recognizable scenarios and react to them in realtime. If you need to process transactions and trigger new messages based on simple statistics or trigger something on a single messages you could use an ESB easily or BAM. If you needed realtime to be able to do more complex calculations and event detection then you could use CEP.
The following diagram which reflects the components of a complete 4-axis Platform:
Enterprise Platform Symmetries
There are also aspects of the Enterprise platform I call symmetries. Symmetries are abstractions Enterprise Platforms provide that make it easy to operate with multiple different choices of underlying technologies or to change things in one aspect without having to change the code of your enterprise application. This is also similar to the idea of “inversion of control” which allows an application to have different manifestations depending on choices made at runtime.
There are many different approaches to the symmetry problems. One is to use standards. Standards are a way to create new symmetries.
Let’s look at common symmetries that are desirable for any application in the enterprise:
Endpoint, Hardware, Network Symmetry
In a messaging architecture everything is messages. The point of messaging is to remove from the applications concerns as much as possible the need to know exactly where the other endpoints are. If there are multiple receivers the application sending the message may not need to know this and it shouldn’t affect its performance if 100 applications are listening to it or 1. It shouldn’t make a difference if you decide later to split the handling of some messages such that some will go to one server and other messages go to a different server.
IMPORTANT LESSON: The spaghetti architecture in the top diagram reflects a hard coded world in which changing anything will cause the system to fail. Since the complexity of the dependencies over time inevitably get more and more complicated this type of architecture becomes inevitable brittle meaning that changing any individual application causes sometimes unpredictable failures in other components. ESB’s, Message Brokers, Registries, provide a way to systematize and simplify changing and extending applications. This largely worked very well in organizations and is why today it is the standard architecture in most larger companies. It works.
Data symmetries
Similarly it is very desirable to be able to change the location of databases, the choice of database, to add columns to a table or remove them, to add data from another database, to replicate the database in different regions and not have to worry about changing the applications that use the data. Data Service Server (DSS) allows you to create a service around the data in your enterprise that hides these details and helps you attain a multi-tier architecture. Storage server and DSS allow you to create symmetry around the data aspect of Enterprise Applications.
Security symmetries
Platform 2.0 distributed architectures should help you build secure applications. Not all platforms include secure technologies but a good Platform 2.0 should include an identity manager and authorization scheme based on standards such as OPEN_ID and OAUTH2 that provide for scalable federated identity management and fine grained entitlement capabilities. Most Platform 2.0 software includes an ability to encrypt messages using various protocols, leverage public/private key cryptography, support for SSL and its variants for various types of authentication. This takes some of the work of security out of the hands of the developers hopefully increasing the security but there are still a lot of loopholes that can be exploited. There is no magic bullet for security we have discovered yet.
Summary
A platform completeness can be defined by it’s ability to satisfy applications along the 4 axis of Enterprise Application development and the Symmetries the Platform supports as well as the Aspects it supports.
This has attempted to describe some of the orthogonal aspects of any problem in the enterprise software space. As a result we have a list of components we have learned compose a “complete” 4-axis Enterprise application suite:
Each of the four axis presents different set of challenges to writing enterprise applications. If a problem has a combination of these characteristics it can frequently be decomposed into uses for each of these types of services. For instance, for long running transactions we have business process engines that can maintain state for a transaction indefinitely. For data collection and event driven type activities we have Service Bus’s. For specifying fast changing business rules we have a rules server. These tools enable you to specify that aspect of the problem succinctly and to use the right tool for the job. This is important because there is a significant penalty to trying to use a tool for the wrong purpose.
There are also common characteristics of any enterprise problem. These are sometimes called “Aspect Oriented” characteristics. Some frameworks and platforms support this ability to abstract from the applications aspects of every enterprise application.
Some of these common aspects that every application needs to deal with are:
a) High Availability / Fault Tolerances
b) Multi-tenancy
c) Common log and administrative interfaces
d) administrative APIs to every service,
e) Start / Stop / Upgrade interfaces,
f) configuration and resources
g) Test interfaces
h) data quality and integrity
i) metadata management
j) user interface design and building
We could spend a lot of time talking about all these other aspect. That is not the point of this particular blog.
When we have an enterprise application to build we usually use the tools we are most familiar with. Sometimes this can lead to very problematic implementations because we are using a paradigm that is wrong for the problem.
The point of all this discussion is to characterize the things we need in a enterprise application platform to see if it is complete. An Enterprise Application platform needs to offer complete set of tools for the 4-axis of enterprise applications and some symmetries and the “aspects.” If a platform contains these things then it can be said to be complete. Some platforms are really designed to solve a special type of enterprise application, not the general problem. That is fine if that’s all you need to build but beware that even simple enterprise problems tend to have elements of each of these components in the specification of the problem.
If you find you need to merge multiple platforms or use a platforms from different vendors (even the same vendor frequently) you will be faced with an integration problem. You may wonder if the platform is buying you all that much if you have to spend a lot of time integrating the pieces of the platform. It would obviously be better to have one platform that gave you everything from the basic set of 4-axis tools. Even though there are standards to make integration of different Platforms easier it is work that is wasted time and potential complexity and support issue.
IMPORTANT LESSON: There is a question I still get by many good programmers. Why should I put anything in the middle between my components? If the only characteristic important to you is speed of communication you may find that this is centrally important. In that case you may find that adding anything in the middle simply slows things down. However, even in this case the problem is speed there is usually no ONE process that is sufficient to meet demand and therefore ultimately you are looking at a complex load balancing scenario where messages are not going directly from A to B but end up going through proxies, load balancers, security devices so that the overhead of putting an ESB or broker in-between in order to give you more flexibility is miniscule. If your message is of interest to more than one party then a MB or ESB can actually dramatically improve performance. We proved this at TIBCO on trading floors where our message oriented publish/subscribe architecture consistently beat our point to point competitors.
CloudRamblings 
One thought on “Component Completeness, what is a complete platform? Using the right tool for the job.”