Enterprise Initiatives

I wrote an article several months ago named Built to last is a thing of the past. Yesterday, at BEA World in San Francisco, a speaker mentioned the phrase...

Built to change, architected to last

I think that this is a great motto and one that teams starting SOA implementations should use as a their vision. Built to change, architected to last is all about agility and flexibility. BEA is touting their own new acronym called Dynamic Business Applications. This new term refers to an architectural mindset based on four principles:

1. Built to change (flexible)
   
2. Embody business processes
3. adaptive
4. agile

This mindset is BEA's response to today's business environment where the business is changing faster then IT can keep up with. The solution is to provide a platform of business processes and services which allow users to design and/or assemble their own composite applications (mashups). The days of buying enterprise third party applications and forcing the users to use the canned processes and features are over. The business changes so fast that third party packages become a crutch over time due to their long release cycles. Simply put, the packages can't keep up with business needs. The answer is take the best of breed features and services from the combination of third party packages, SaaS solutions, and custom code and present a common interface that integrates all of the functionality together into a single view of the users' workflow.

Dynamic Business Applications is a shift to a world where applications are human made and designed for the way people work. The IT team delivers business processes, business services, core infrastructure, and integration services. The business can then create their own composite application by assembling all of the pieces together. Think of it as the Lego approach. The IT team builds the rectangles, squares, wheels, and various connectors in all different shapes, sizes, and colors. If the users want to make a boat, the choose all the pieces necessary to make the boat. If they want to make a plane, they choose the pieces necessary to make a plane. The users did not have to wait for IT to build them a boat or plane.

To accomplish this, IT must work closely with the business to identify the core business processes and services. This is where it is extremely helpful to establish a SOA roadmap. Once you have identified the collection of business processes and services in some key area of the business, you can then prioritize your deliverables by delivering the processes and services with the highest chance of reuse first. This greatly improves your speed to market in the long run.

Another shift in thinking that should be mandated in organizations is to move away from creating reports and move to creating information. My philosophy on this topic goes like this....

You should only develop reports if it is an output of the system (ie. bill, invoice, purchase order, etc.). Otherwise, IT should leverage business intelligence and deliver data as content to the users with a tool that allows them to format the output and drill down into the data as needed.

Why do we continue to pay developers to write custom reports only to get frequent change requests to change or add new columns, create multiple output formats to please different individuals' preferences, and make changes to group or sort things differently? Not only is this expensive and an inefficient use of people's time, but the users typically have to wait for IT to make these changes. Although these changes may be quick to make, it may be a long time before the change is high enough on the priority list to get worked on. Wouldn't it be better to present data to the users and give them self service capabilities to define their own reports, create their own dashboards, and do their own what-if analysis?

IT needs to become an enabler instead of a bottleneck. We should stop building custom applications and start building the building blocks that can be assembled into Dynamic Business Applications.