Sunday, January 20, 2008

Evolving Opportunistic Solutions

Opportunistic projects (software solutions) are the essence of the progress in all organizations. These projects provide valuable ad-hoc gains in productivity to the people who need help the most. Such projects usually don’t have a formal budget, have one or a few people running it, and usually reside outside of enterprise architecture environment or go against the formal way of doing things. But these projects exist because they provide the benefit the core IT organization cannot.

One example may be auto generation of pre-canned reports for a loan processing clerk. In this case an existing FICO score provides good information about the risk level of a potential borrower, but a loan procession clerk may get an additional level of insight, and reduce risk to the bank, by looking into additional publically available information. Usually opportunistic solutions target a small specialized niche, such as pre-canned reports for farm machinery loans. But as loan officers across bank divisions talk to each other, they find out that these reports are insightful for other loan types, and eliminate the need to do manual research. Now all loan officers want these reports to be included as part of their loan application paperwork. Loan division chief requests the opportunistic software solution owners to provide reports to everyone. Will this work?

A responsible software architect who recognizes this situation needs to act fast. There are many red flags in this scenario that may turn a well respected idea into a disaster. First, it should be clear that unless the designers of the opportunistic software solution thought about scalability and extensibility during design it may not be possible to produce more reports without rethinking entire approach. Perhaps the solution taps into an already overtaxed database system that goes offline periodically. Secondly, the growth problem may not only be technical in nature. May be the business process supported by the software solution is not scalable. It may be that the software generates reports and emails them to users automatically, but requests for reports are being processed manually. Perhaps the reactive response to support the requested increase in demand would be to add staff and throw hardware at the problem. That may last for some time, if system allows multiple users, but eventually the opportunistic solution will require features that can only be obtained from enterprise services (e.g. SMTP service, enterprise auditing, directory services, etc.).

The moral of the story: build on success of opportunistic solutions. Recognize patterns, analyze change impact, educate solution owners on the natural evolution of successful opportunistic solutions and on the differences between ad-hoc and enterprise solutions, understand how requested change fits into the existing and future organizational enterprise architecture, and finally show the solution owners that the demand for their service will only grow with time.

Constantin K.
Firebrand Architect™

No comments:

Blockchain learning path for Enterprise Software colleagues

I wrote this post to document my learning path of blockchain concepts and Ethereum technologies while keeping my “new to blockchain” collea...