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'

Performance Engineering: Approaches

As a software developer we continuously need to design and develop solution for the complexity thrown upon them. It is therefore very important for one to keep oneself abreast with different tools, technologies and methodology, while, having said that, I'm not exactly asking to run after them but it makes sense to stop and at least get the central idea about a given tools etc. because you would at least learn a new perspective of solving an existing problem or better still identify a potential problem with the existing solutions.

AspectJ appeared multiple times during my search efficient techniques to profile my application for conducting performance engineering exercise. I decided to take the plunge and try my hands with this methodology.

The underlying theme which the authors have tried to sell this methodology to us developers by exposing the shortcomings with object orientation, according to them, the OOAD methodology shines for solving the core problem but falls short to provide bells and whistles for the enterprise applications efficiently. They refer it to as 'Cross-cutting Concerns', concerns which are not exactly the part of the core problem (subject to the context) and form the supporting functionality. Simplest example is that of logging, frequently logging code is tangled with the core logic itself, thus forcing the developer to focus on far too many things at a time.

This seems to solve the 'Architects- Dilemma' where one is always trying to do the balancing act between the 'Over-engineered' vs. 'Sloppily-designed' systems. AOP seems to provide extension points to the application to provide utilities later. That serves us well because, whenever an extension is required only new code is written without modifying the existing code.

There seems to exist good amount of tooling support AspectJ for Eclipse, JBoss AOP etc. can't really compare and contrast them at this point in time but I have a feeling that AspectJ has fuller support than JBoss.

There are interesting articles available on IBM Developerworks to give a head start to the subject.

Another, technique that needs to explored is JMX that seems to provide JVM level support for application monitoring.

My primary approach to the problem of monitoring application for performance was to create custom class loader using java reflections API but I have a feeling now that this approach although very powerful is also quite complicated and error prone.

May be I should focus on AOP for the time being for better turnaround time in the longer run, also because learning this approach may expose me to solve other problems in a more efficient manner.