Mashups combine, aggregate and remix existing data from various sources (databases, spreadsheets, websites, Web Services, RSS/Atom feeds and unstructured sources) and deliver information in a actionable format including better visualization.

Visualization is the greatest benefit derived from Mashups and accordingly most Mashups today are hosted as Internet sites, providing visual representations of publically available data. Mashups are relevant and useful both in Consumer as well as Enterprise context. Enterprise mashups are secure, visually rich Web applications that expose actionable information from diverse internal and external information sources (wikipedia).

Mashups being “content aggregation” naturally gets compared with Portals.  Portals can be said to be legacy while Mashups are the upcoming ones in-line with Web 2.0 and Social Computing Trend. Typically creating Mashups do not require programming skill and can be achieved by visual wiring of GUI widgets, services and components together. Another key difference is in the type of Aggregation and the final output arrived. In Portal the content is presented ‘side-by-side’ without overlaps (“Salad bar” style) and in Mashups the content is combined in any manner resulting in hybrid output (“Melting Pot” style).

Enterprise Mashups solves business challenges by empowering the Users – by allowing the users to combine and remix different data in new ways, providing new insights into corporate data. Effective Enterprise Mashups adoption would provide significant benefits to organizations in terms of speed, agility and innovation.

 IBM’s listing of the characteristics of Enterprise Mashups as given below is quite complete:

• Simple, flexible applications that solve day-to-day problems
• Can be created in minutes, hours, or days (given heavy reliance on reuse and lightweight integration techniques)
• Can be “situational” in nature – easily customized to meet an individual’s unique needs
• Mashing of functionality from different sources supports new insights
• Often supports self-service application development
• Can help make Service-Oriented-Architecture (SOA) more business-relevant and visible, increasing reuse of services and widgets

Refer to ftp://ftp.software.ibm.com/software/lotus/lotusweb/mashup/EPW14002-USEN-00.pdf for a whitepaper titled “The business case for Enterprise Mashups”. Another interesting article on business case for Mashups is available at http://blogs.gartner.com/anthony_bradley/2009/06/11/you-cant-build-a-business-case-for-enterprise-mashups/.

According to Gartner, “By 2012, one-third of analytic applications applied to business processes will be delivered through coarse-grained application mashups”. Coarse-grained mashups overlay analytical insights, such as queries, scores, calculations, metrics and graphs, onto the graphical user interface of the operational application. Standards like Enterprise Mashup Markup Language (EMML) and products like IBM Mashup Center are accelerating Enterprise Mashups adoption.

Today there is no two opinions about the need for business to be Agile and every other technology/business trend aims at providing/improving agility to enterprises. Agility is a concept that incorporates the ideas of flexibility, balance, adaptability, and coordination under one umbrella (source: Wikipedia). Measuring Agility – and thus finding out if the initiatives are really effective – is a bigger challenge. I have found the following aspects – categorized into two – to be quite effective in measuring Agility related to IT (from an application / product / initiative point of view).

Result driven

(ie., looking at the results, gives an indication of the “Agility” at any point in time):

1. Perception of Business: Business feedback on how IT is able to support business – existing as well as changes

2. Time-to-market : Time between business suggesting a change, when the change is actually taken up, and how long does it take to implement the change and went it actually gets live.

3. Maintainability of the system: The time and effort involved (and hence the cost) in handling changes; frequency of changes to the system can also be a factor (for e.g, if the system is not rule based and have externalized control tables, even changing certain parameters may mean changing programs and testing the same);

4. Quality of the system: Number of bugs reported, Number of severity 1 or 2 bugs, time taken to sort out the bugs, instances of Debugging resulting in additional bugs

5. Support(ability): Time and effort involved in supporting the system; responsiveness of the support teams, number and %age of problems resulting in program level changes vs Data level changes

Situation driven

(ie., looking at the current environment focusing on aspects which would have an impact on the “Agility”):

1. Technology stack – OS, DB, Language, any other middleware and their versions – and details on whether they are on the versions that are supported, latest versions, obsolete technologies – as well as availability of skills on each of these (say as a %age of their IT force – as well as from general market trend)

2. Database size as well as Archival strategy – it can play some role - more from a migration strategy view as to whether all the data needs to be migrated to new system (or) if some of it should/can be archived 

3. Interfaces – the kind of interfaces that this system supports can be another factor. If it has reasonably good external interface support – which lends itself to newer requirements like Internet support, integration with other applications… then the longer it can be… without having any negative impact on the business.

4. Integration Architecture – a well defined integration architecture helps in reducing the interdependencies across applications and hence make it easy for making changes

5. Infrastructure utilization and Vendor relationship – how quickly the infrastructure can adapt changes in volume, work load and how easy to upgrade/downsize

6. Level of Reuse – Services that are consistently reused across the organization can help in making changes faster (as it is one place to change and test – and implemented across – instead of replicating all through). But this may have a downside, when the change requirements for the same service can arise from multiple sources – which can be conflicting – or at least may make one part of the business feel that their changes are not taken up (such issues would be brought out from the “Results” aspect).

While the above approach is quite adhoc and can be used as to get the first cut opinion, there are many detailed methodologies of measuring agility at a Enterprise level:

• Cutter group has an Agile Assessment offer, where they gather and monitor five core metrics: quantity of function, productivity, duration, effort, and reliability (http://www.cutter.com/consulting-and-training/agile-assessment.html).
• Website of Laurie Williams – leader in measurements of agility – of North Carolina State University http://collaboration.csc.ncsu.edu/laurie/ has various references and publications.
• Agility Index Measurements (AIM) covering Internal Team Communication, External Team Communication, Team Morale, Repeatability (builds, configuration management, tests, etc) , Code Quality , Team Skillset and Capabilities , Sustainability and Scalability, ‘Crisis / Crunch’ mode management.

Most people agree with Charles Edwards (of Agile EA) comment, that though software development and architecture has been making excellent progress over the past two decades, the same cannot be said of Enterprise Architecture. There are ongoing debates and discussions on topics like Is Enterprise Architecture dying? What is killing Enterprise Architecture? Is there any market for Enterprise Architecture?

The typical drawbacks of Enterprise Architecture (EA) are observed to be:

1. It takes way too long and requires too much effort
2. Not able to prove that significant value is being created
3. Lack of Communication

In an attempt to solve the major drawbacks of Enterprise Architecture, other methodologies (at times referred to as third generation EA) have come up. Still there is no consensus and as practitioners we realize that the hybrid approach is what works best.

From this perspective, the following key points could be directly used by practitioners of EA as a step toward agility:

1.    instead of trying to make a perfect architecture / model – which takes a lot of time and effort and hence quite detailed but not really more usable or correct (as with time the changes would have happened and the model may not reflect the current status), aim at a simple, usable and meaningful model that makes sense to both the Business and IT people and hence really effective (as people really would read and use them!).

2.    Not rely on a specific modeling approach and but use a variety of tools to depict the information and adopt an “iterative and incremental” way to build it. The key is to use the “Right approach – with the right level of detail – for the right context”.

3.    Look at the whole picture – using the various perspectives which are depicted in multiple artifacts.

AgileEA is a free open source EA Operational Process. It is a framework that is designed to either use as is, or to tailor and publish your own Enterprise Architecture Operational Process website. Right now, the site seems to be under maintenance - some time back it was in Beta and asking for suggestions. A whitepaper on Agile EA – Phases, Iterations & Discipline by Charles Edwards is available at http://www.agileea.com/Whitepapers/AEA_Phases_Iterations_Disciplines.pdf.

IBM has been driving to improve DB2 utilization in the cloud and a series of announcements including the DB2 virtual appliance shows a trend where we can expect more. To quote IBM, its DB2 view of the Cloud Computing is “what technologies and business models can we bring to market to help our customers realize the promise of the Cloud Computing”. The promise of cloud computing is its potential to reduce costs and improve agility.

IBM’s target users for DB2 on cloud includes everyone – Developers, Startups, SMB, Enterprise, Service Providers, SaaS Vendors. Availability of no-charge DB2 options in cloud makes it worthwhile to start exploring DB2 in cloud.

IBM’s DB2 Strategy around cloud computing falls into four key points:

• Deliver key technologies to support its customers private cloud initiatives
• Partner with key public providers to fully integrate DB2 into the ecosystem
• Provide robust DBMS for SaaS vendors
• Offer terms and conditions and pricing to make DB2 the best DBMS for the Cloud.

Technically its threaded-engine Architecture that minimizes memory requirements and enables efficient use of multi-core processors used in virtualized systems, Autonomic features like Self Tuning Memory Manager that reduce administrative costs, Support for various development platforms like Java, .Net, PHP, Ruby on Rails etc. makes DB2 an excellent choice for cloud environments.

In cloud context being technically good is only one part of the solution. Cloud computing is expected to reduce costs, improve flexibility and enhance agility and unless these benefits are provided for success would remain elusive. IBM seems to be accepting this reality and showing its willingness to adapt and coming up with various licensing and pricing strategies.

DB2 support for Private cloud is centered on availability of optimized DB2 in Virtualized environments including DB2 virtual appliances, standardizing and enhancing DB2 server provisioning and automation features. The sub-capacity pricing (now available on all DB2 Editions) where the charges are based on the system usage and not the full-capacity of the hardware coupled with the option of licensing on a per-day basis provides the basis for cost-effective virtualization.

DB2 public cloud presence involves mainly partnership with leaders in the cloud space and includes:

• Amazon – public cloud infrastructure
• RightScale – Platform for cloud management
• Morph labs – Web application Hosting Infrastructure
• Corent – Rapid SaaS development
• Canonical – DB2 Virtual appliance running on Ubuntu cloud computing platform

Additionally, DB2 Enterprise Developer Edition is available in IBM Smart Business Development and Test Cloud.

DB2 in Cloud is available under a variety of pricing option. The free edition, DB2 Express-C is available at no cost but no IBM support. IBM points out that there is no limit on the database size or number of users making it an ideal choice for SME as well as developers. DB2 Express-C is easy-to-setup, easy-to-manage, and includes self-managing capability and also comes with the pureXML technology suited for Web 2.0 applications. For more scalable DB2 required to run large business database loads, customers would have to pay DB2 licenses.

Customers who already have a DB2 license can use it in the cloud with no additional cost and IBM would continue to support it. In between this free and perpetual license, various pricing options like pay-as-you-go, hourly usage fee, purchase optional DB2 support etc. are available.

IBM wants to position DB2 as the DBMS of choice for the SaaS vendors who aim at exploiting Cloud computing trend. The advanced autonomic features, technologies like Deep compression and pureXML coupled with attractive pricing is what IBM is betting on to achieve this.

DB2 in cloud – or for that matter any other Database – is not yet ready to handle mission-critical or I/O intensive applications. But there is a whole suite of areas that could right away start exploiting cloud – Prototyping, development and testing, periodically run applications (end-of-month processing or day end batch jobs), handling variable workloads without dedicating resources, database backups, databases for disaster recovery, Web 2.0 Applications.

Enterprise Architecture has been there for over two decades now and still means different things to different people. For some it is a graphical model which excruciating level of details, while in the other extreme it is viewed as a practice that brings in business value.

Zachmann, TOGAF, FEA and Gartner’s EA practice are the four significant EA methodologies that are there in use today and most others are a combination of these. Of various artifacts that dwell on Enterprise Architectures and their comparisons, I found “Comparison of the Top Four Enterprise-Architecture Methodologies” in http://msdn.microsoft.com/en-us/library/bb466232.aspx the effective one is bringing out the differences. In spite of the differences in the understanding and approach of what constitutes EA, the objectives are necessarily the same “Business-IT alignment”, Agility, Cost Reduction and Improved Value.

Enterprise Architecture, though seen as an IT initiative (probably due to the reason that it has been handled by IT personnel), has to do more with Business than IT. In general, the essential reasons for developing an EA have been and remain as:

•Alignment – ensuring the reality of the implemented enterprise is aligned with management’s intent

•Integration – realizing that the business rules are consistent across the organization, that the data and its use are immutable, interfaces and information flow are standardized, and the connectivity and interoperability are managed across the enterprise

•Change – facilitating and managing change to any aspect of the enterprise

•Time-to-market – reducing systems development, applications generation, modernization timeframes, and resource requirements

•Convergence – striving toward a standard IT product portfolio as contained in the Technical Reference

Right now, Enterprise Architecture has reached an interesting phase where it is no longer looked upon as a technology or infrastructure or even application related. With Enterprise Architects today reporting to CxOs, the EA charter today includes enabling Business Strategy and addressing business issues.

Though it sounds like an ideal situation, it definitely remains an uphill task for Enterprise Architects. A survey from Forrester points out that lack of support from business is a common concern and improving perception of EA as a common goal expressed by Enterprise Architects.

Both business and technology are changing at a rapid pace and even bringing paradigm shift. Businesses are expanding, merging, de-merging and time-to-market has been shrinking and shrinking. Similarly technology advancements like Cloud computing, Software-as-a-service, COTS are making Application and Technical architecture of lesser importance than hither-to they have had.

Business Architecture, Information Architecture and Integration Architecture are the areas which are to be focused at by Enterprise Architects. Significant progress in these areas coupled with delivering business benefits, that too quickly, is what is expected from Enterprise Architects today.

In most organizations, Enterprise Architects currently spend most of their time in arriving at detailed models which no one else are able to use effectively, in creating detailed level of standards and guidelines that result in frustration during implementation, in acting as enforcement agents of the EA guidelines created and in trying to meet the immediate need of the business – giving short term the priority at the expense of long-term goals.

To enable the level of detail which Architects where arriving at and also to handle localized requirements, most large organizations had Enterprise Architecture groups at local or national level. And this trend is again changing with the focus of Enterprise Architecture increasingly becoming global.

Global Enterprise Architects should streamline their focus and efforts on high impact, high priority areas that are in alignment with the business strategy. Most of what they are currently doing cannot be ignored altogether – and these activities can be relegated to local and regional Architecture groups.

With the improved EA charter, aligning to any single EA approach may no longer be feasible and the best thing to do is to use the right set of tools, producing artifacts at the right level of detail, and most importantly within the right time frame. Communication – that always was essential for the success of EA, has become crucial today.

Enterprise Architecture, as any other discipline, should adapt itself to the changing demands and trends and agility of the EA is what would ensure that EA provides the benefits it promises.