Stories from the trenches

Reporting live from the "technology side of business" I find that the 'geek quotient' required for us to remain in the role of that of a 'technical advisor' to business has only rose higher and higher with an added expectation to empathize with business challenges and continuously provide technology tools for business to increase its productivity and profitability. We seek to achieve these goals by;

• using technology to reduce wastage and resource consumption in the business process
• provide high level visibility to the business performance to ensure process re engineering are carried out in a timely fashion
• monitoring key performance indicators to determine if the business processes are helping the organization to reach its goals.
• enable business owners in taking effective decisions.

If you are planning a career in the industry you need a good grounding in how technology management differs from traditional methods. Writing code is so year '1998. The important skills are;

• domain knowledge: this is the most important attribute, I strongly believe unless you do not understand the history, politics and economics of the software development activity in your current project you are like a labourer who is merely digging the soil rather than a labour who is digging soil to lay the foundation stone. Associate the purpose with your job, it will always help to use information technology and electronic commerce to reduce costs and open up new market (SAAS, PAAS delivery models etc. more on this later...)
• data modeling: good that you know XML as a technology, but that adds no value to the business if you are not able to create effective data models using which much of the information flow can remain native to the system without ping-ponging between marshaling and marshaling thus saving precious computing resources without making them platform dependent, thus, creating an infrastructure stack which understands and processes the 'same' object model to support truly heterogeneous distributed computing.
• rules: all these years you have been writing those plumbing code which soon becomes ugly and stinks badly but then you thought it is the business logic and where else do they stay, aren't their ways to externalize business logic from code so that they can be changed dynamically and easily when needed without going through the painful maintenance cycle. Believe me even business look upon them as bottlenecks !! so it is loose all situation. If you want more agility start with a rule based architecture where in you extract the frequently changed business logic into Rule set and Decision Tables using the rules framework like JBoss Drools or Jess.
• AOP: Aspect oriented technologies seek to cater to the cross cutting concerns of an application, much literature can be found on the web, the key point I want to drive home here is that if one is in the process of creating a new system (s)he can focus on solving the core problem without adding features which he is not too sure and which can always extended later using AOP techniques or that in an already existing system by adding a dimension to your application.

This article provides a high-level view of business challenges in the light of frequent change in business scenarios on account of mergers, acquisitions, government policies, market conditions. Business today seeks agility the above set of technologies allows you to flexibly treat elements of business processes, and the underlying IT infrastructure, as standardized components that can be reused and combined to address changing business priorities. By understanding the common business problems through architectural scenarios, such as those in this article, customers can get started in a more prescriptive way with 'Technology'