Tuesday, November 13, 2007

Architecture for Business Improvements

Read a very nice article on Microsoft Architecture Journal on 'Business Improvements using Software Architecture'.

My thoughts on the same follows...

Traditionally, in IT services, the solution implemention happens in passive model. There is no consulting element involved. The true intention of the outcomes of the business requirements is not understood in detail like productivity improvements, business enablement, Growth potential, etc.. These factors need to be understood purely from a business perspective.

These perspectives need to translate to architecture decisions in terms of usability, extensibility, performance etc. These architecture decisions also need to be in sync with enterprise architecture standards.

If these two factors are not taken into consideration during the solution architecture phase, then the system will end up as another silo.

From project execution standpoint, we need to factor effort and time for involving these elements at the relevant stages in the SDLC cycle.

Enterprise Mashups Vs Composite Apps

Today morning, while I was driving, I was listening to 'Enterprise Mashups' podcast from Gartner.

It immediately triggered one interesting question - what is the difference between Enterprise Mashups and Composite Applications?.

Some of the observations:

1. Enterprise Mashup are addressed to 'Long Tail' of the enterprise. They are primarily targeted to individuals or small teams. Composite applications are the cousins of Mashups in Enterprise applications world.

2. Enterprise Mashups - Development and Management/Governance is left to individuals/Community.

3. Enterprise Mashups are 'assembled' by individuals/small teams. Composites are 'built' or 'developed'.

4. Enterprise Mashups are not supposed to have any business logic on its own. Composites can have business logic / orchestration logic.

5. Composite applications are much more critical/serious in nature compared to Enterprise Mashups. So, Composites are typically left to IT development teams officially. Composites require a strong governance as well.

6. Enterprise Mashups are based on web 2.0 'Culture' rather than 'Technology'. Composites have their roots in 'Mashups' and 'Web 2.0' but there is more technology flavour to it.

7. Enterprise Mashups are loosely-coupled. Composites are also loosely-coupled, but not to the extent of Mashups.

I think, from pragmatic perspective, its is the company's 'culture' and 'organization structure' that is going to be the key decision factor in web 2.0 or Enterprise Mashup initiatives.

From today's world, it looks like the 'solutions' are pushed to the IT shop to try out new things like web 2.0, Mashups, etc... What is the need of the hour is 'Identification of problem statements or potential pain points or improvement areas' that could be alleviated by these new solutions.