Monthly Archives: February 2010

The Real Impact of IT Owning Your SOA Effort

I had a great lunch discussion today regarding the impact of ownership of SOA within the business. As I have discussed multiple times, SOA is about business services, not technical services, but the reality of this point is lost in semantics.  The following illustrates the different perspectives that each have and how that impacts the overall SOA initiative.

Let’s look at two business capabilities in real estate: renting the building space (sales) and drawing up rental agreement (legal).  Each of these business capabilities are effectively services to the business.  In order to operate effectively, they need to share some basic data, such as property listings and renter information (CRM).  They also operate synchronously as part of a business process that results in the execution of a rental of a property.  Otherwise, they operate fairly autonomously from each other.

From the business’ perspective, at a minimum, they’d like one and only one of each of these capabilities, each delivering in a consistent manner. Sometimes, that is not possible. Perhaps, there needs to be two distinct sales teams due to regulatory or licensing issues. In this case, the business will still want the multiple sales teams all operating in a consistent manner, using the same forms, if possible, and interacting with the legal department to draw up the contracts in a consistent manner. The consistency is what enables the business to operate efficiently even in the face of redundancy.

In this particular case, I believe, while not optimal, it is perfectly okay for there to be redundancy of certain information systems in the delivery of each of these business capabilities as long as it allows the business function to deliver consistently and efficiently. For example, if each of these groups had selected a different portal product to provide access to the property listings, that would be acceptable as long as they were operating off the same listings service. Forcing these groups to consolidate on a single portal product is not going to provide any additional efficiencies for these groups or simplify their ability to deliver.

However, what we see happening in the industry, is that SOA efforts are being led by IT and not by the business leaders. Hence, IT views the problem from a systems perspective and sees the need to remove redundancy at the information systems level. So, instead of focusing on business capabilities and making sure that the business rules, processes and goals are being executed consistently and that redundant business capabilities are consolidated, they look at the redundant portals and identify them as a target for consolidation, as so they should.  ITs job is to keep IT costs down and are rewarded by simplifying the work of the IT department.  However, as I used to remind my developers, it’s not about what’s easier to code, it’s about making the jobs of the users easier, that’s why they pay us.

The result of IT forcing consolidation of portal products is some cost savings, but interruption and change for the business. The overall productivity losses within the business function due to the interruption is typically never identified, let alone measured. Users will need to be re-trained on the new portal, things won’t work initially and users will become frustrated and be less productive. All of this for the possibility of reducing the costs of managing one additional piece of software.

I say let sleeping dogs lie. There are plenty of real information management costs in most businesses that eliminating will offer a real benefit to the business’ bottom line. Clearly, both of the aforementioned business capabilities need to be operating off the same customer and listing data. There’s plenty of work to be done by IT without focusing on needless change.  Eliminating the additional software licensing costs are penny-wise, pound foolish when the real impact is analyzed and assessed.

With regard to SOA, IT will view SOA as an IT effort that results in consolidation of technical capabilities.  That’s their task and that’s how they are rewarded.  IT is not rewarded for improving productivity in payroll by improving the end of month process.  And, therein lies the flaw in the system.  We have become heavily reliant upon our data and applications to run our business, and therefore, IT has become a critical function of the business.  Yet, the business world rewards IT for running with as low of an overhead that can be comfortably be achieved without putting the business at significant risk.  If we really expect SOA to live up to its promise, it is going to have to become an effort that is undertaken by the line of business as they reorganize for streamlined operations, or, if we’re going to let IT own the SOA, then we are going to have reward IT for improving productivity and usability of the systems in a manner that is best for the users and not necessarily IT.  That is, we’re going to have to let them focus on actually aligning the information systems with the needs of the business and not force the business to live with the limitations of the systems.


Architecture: 1000 ways to skin the cat, either way, the cat’s till dead

Thanks to @jadkins for the colorful ending to that cliched saying, which really got me thinking. Sometimes we just make certain aspects of architecture too difficult for no reason. Good design is important and can have significant financial impact if done incorrectly, but chances are the negative impact comes into play during the engineering effort, not during the architecture. To clarify my point, one must first understand what architecture is really focused on and how that differentiates from engineering.

For example, if we’re designing a solution for financial services products. I can choose to take a framework approach to architecture in which we identify the common financial services components, such as securities and instruments and expose the manipulation of these components through the framework. Then we can continually add new algorithms to manipulate these same components in a modular fashion. Yet, another approach might be to examine things from the perspective of the buyer and the seller and allow each financial product to implement it’s own representation of securities and instruments and orchestrate the process of selling and buying.

Either of the aforementioned scenarios is a viable architecture. In the former scenario, we can develop new computational models very quickly as long as we don’t change the definition of the semantic elements. However, it can be a bit rigid since all new products must be able to define the components of its product based on these definitions. Also, sharing these products across trading partners becomes more complex.

In the latter scenario, we have a more service-oriented approach, focusing on the consumers and less on the definition of the products themselves. Hence, each service is unique, and may produce redundancy in defining the elements used to create a product, but we can orchestrate buying and selling across products in a common fashion. This approach facilitates incorporation of a much wider community since agreement is not required for the representation of elements to create a new derivatives product.

Which architectural approach is better? Well, as any good consultant will tell you it depends on your goals. If your goal is to allow your big brains to develop new models quickly to identify market making opportunities, then the first approach sounds ideal. If your goal is to enable a new derivative product to be treated as a single instrument even though it’s comprised of securities that are bought and sold across a variety of exchanges, then the latter approach will probably suit your needs better than the former.

Neither scenario is optimal or guaranteed, but they both represent a means of simplifying the system enough to extend it over time without considerable re-work efforts.

When complete a design goes through an engineering effort where a software engineer will take this design and “press” it into software. During this effort, decisions are made about platform, programming language, external libraries, software development methodology, etc. Any one of these decisions, or a combination of them, may lead to the undoing of the great abstract architecture designed. For example, if the system cannot scale to the volume of financial services transactions, then that would be one major flaw. Using an open source library that ends up having a major security flaw is another potential flaw.

These scenarios are not very different than design and engineering in any other industry. The architects can design the most awesome car or impressive building, but if the engineers select the wrong parts or use inferior materials, the resulting product will never allow the architecture’s brilliance to shine through. Note, manufacturers put significant effort into ensuring that their designs will work by building prototypes and testing against known environments that the product will have to operate under. Thus, from this perspective, architecture is responsible for putting forth a design that is credible before engineering commences.