10.26.10
Really Big Can Be Really Bad
[Cartoon]
Doing a really big software project can look really good at the beginning and then turn out to really be a nightmare.
The bigger anything gets, the more complicated it gets. The bigger anything gets, the greater the opportunity becomes for unforeseen consequences. Software projects seem to amplify these natural occurrences when really big efforts are undertaken.
One of the senior managers I once reported to told me he had no problem getting what he asked of IT. The only problem was, his IT folks often presented him with what he asked for and he had forgotten why he asked for it. Somehow the effort to meet his request had gotten too big, took too long, and the senior manager had already overcome the problem and moved on.
The effort that business organizations have gone through to get their SAP, Oracle, or IBM fully-integrated-applications up and running is enormous. Most of these organizations are pleased with the final results, but not happy with the time it takes to make business-driven changes or integrate with other applications.
There is another way that supports thinking small. This way is “componentization”. It is a way that requires discipline. This is a way that requires very competent Enterprise Architects to set the environment for success.
Componentization is at the core of the SAP, Oracle, and IBM solutions. Each has their own approach as do other vendors of integrated applications. Although under the covers, each vendor solution utilizes the standard concept of Service Component Architecture to define all of the processing components. Even the business process management is implemented using the Business Process Execution Language.
Microsoft is somewhat different. They have not embraced Service Component Architecture. They have a different idea. The idea is similar, but different enough so a business would use only Microsoft products. Conceptually, though, they are just like the other major vendors in the application of componentization.
These organizations have some of the best Enterprise Architects in the world directing their product development. They recognize the importance of componentization in the delivery of business solutions, as should every organization. These superior architects also recognize the importance of using industry standards.
Every organization’s Enterprise Architects must fully understand the standards of componentization and apply those standards that will bring the best value to their organization. It is a bit of a copout to become an “IBM”, “Oracle”, “SAP”, or “Microsoft” shop. It is a copout because the business organization is allowing another organization to determine how and when business solutions are provided.
Think small. Think components. Realize that our thinking is going through a significant shift. With all of the challenges of information sharing, automating business process management, cloud computing, social networking, and the semantic web, thinking small is the only approach that will work.
The Enterprise Architects can see what is coming and are already preparing. They know that this will be their time. Corporations will be able to completely focus on their business, and automation will be viewed as an agile enabler. Automation will finally become the self-service contributor that the Corporate Office has always wanted it to be. –Enterprise Architects Masters of the Unseen City
Closing the Business / IT gap.
