Saturday, December 12, 2009


Those were the days when we as Architects have to put effort on planning deployment architecture. Usually, in a typical System Architecture Definition document, ‘Physical View’ or ‘Deployment View’ will be one of the 4+ 1 views. Arriving at deployment architecture with the exact no. of infrastructure components like Servers, SANs, routers & switches, networks capable of handling a pre-defined bandwidth etc requires a series of activities that include capacity planning exercise, stress testing, load profiling analysis etc.

‘Application Agility’ is the driver behind many SOA and BPM initiatives. Applications were architected based on Service Oriented Architecture to respond to the changes in business rules or business processes because of market situations & regulatory compliance requirements, But ‘Application Agility’ will not alone provide true agility. Change is not only confined to business process / rules. Another dimension is ‘Volume’. Suddenly there can be a spike in no. of users buying products or browsing a web application. That type of change will pose a different challenge. An application architected based on SOA cannot respond to that type of change, unless it is deployed on appropriate infrastructure. That too, if the volume increase is beyond the estimated numbers that are considered during capacity planning exercise, then application will tumble. So, if there is a mistake happened in the capacity planning exercise or if the volumes are under estimated, and then there will be a business breakdown. Unless we have a capability where infrastructure components will be available even when the application faces unexpected demand so that it will survive under such peak loads, we cannot avoid applications breakdowns. That capability can be called ‘Infrastructure Agility’, where infrastructure will be available on demand.

With the advent of ‘Cloud computing’,   Infrastructure Agility can be easily achieved. Like SOA, Cloud computing achieved top buzzword status. In Aug’09, search for “cloud computing” returned 92 million hits!  In the context of cloud computing, the activities like capacity planning or even the role ‘Infrastructure Architect’ may cease to exist!

To assess an enterprise’s maturity in terms of SOA, we have many SOA maturity models provided by the product / platform / IT service vendors like IBM, Sonic, Pega, Infosys and Collabera. The highest level indicates that enterprise’s services are optimized and are well suited for partner integration. In the light of availability of cloud computing, one more level can be added which would indicate about enterprise’s capability in terms of deploying services in a cloud environment and leverage its benefits. They can be marked ‘SOA+’.

There are many vendors playing in the cloud computing arena: Microsoft, Google, Amazon, Akamai, Rackspace, Enki, Terremark etc.

Beauty of Microsoft’s Windows Azure is its capability to leverage existing expertise of .Net folks on Visual Studio. There is no any extra learning curve for the guys who know to do development based on visual studio. They can leverage their existing skills to develop cloud aware applications & services. This makes Windows Azure more attractive both from developers’ perspective and also from enterprises perspective.

Let us hope to have more ‘Windows Azure’ days.

Wednesday, December 2, 2009

Models & Maturity of an Enterprise

When it comes to embarking a larger initiative in an enterprise, it will not fly high unless it has a good, concrete buy-in from different stakeholders, especially from business. Whatever may be the approach either it is EA or SOA based initiative, business stakeholders should be convinced with proper justifications. 

In addition to business metrics oriented reports, if we use models extensively, it will also help in making stakeholders clearly understand what is planned to be achieved through big initiatives. Models also play a vital role in bridging the execution gap between strategy & operational infrastructure. Models will help in ensuring that the strategy that is envisioned is executed; it is transformed in terms of processes & operations.

Assessing the maturity of an Enterprise – in terms of business / technology, against the industry standards/benchmarks will be key driver for arriving at a strategy. Usually maturity models are considered to be the representation of standards / benchmarks. Different levels in a maturity model bring a quantitative dimension. One such maturity model is depicted here :

Saturday, October 10, 2009

Common Show Stoppers in Enterprise Applications Rollout

In any of the Enterprise applications / systems development, the issues that we face can be categorized across following 4 categories :

1. Environmental issues

a. "In UAT environment it is production it is not working " [Because of mismatch in the versions of the softwares installed, Hot fixes applied , Patches updated, some files corrupted , Mismatch in the keys used while using encryption / decryption, registry issues because of some corruption, inconsistency in configuration (DB server, APP. Server etc.) – sanity issues]

b. "Yesterday it worked.Today it is not working " [May be it is tested with some other data…today with a different data, Un-audited software installations etc.]

c. Some times bugs in the platforms will get revealed only under some circumstances which even platform vendors may be un-aware of !

2. Resource Availability
    [This may lead to non-reproducible errors and hence affects reliability]

a. Availability of DB connections / other legacy resources
b. Thread pool

c. RAM, CPU etc.
d. Instability in the availability of the common resources (which are also used by other applications )
e. Shortage of the resources in the peak loads.In this case problems will bubble only in the peak stage. We will not be able to reproduce it hence it will lead to lots of confusion

3. Resource Accessibility

a. Access to some resources is limited to some roles – DB connections , User roles not mapped / configured in the legacy resources
b. Some times there will be a policy because of which password will get expire / reset
c. Missing of credentials synchronization across resources

4. Interoperability

a. Types exposed through a service cannot be consumed by a client application developed in a different platform
b. Data types adopted by the data access layer not compatible with the Database system

If we can have processes / policies / governance that are devised around these categories; if we start any development with the consciousness of these factors in mind, then any enterprise application rollout will be a smooth ride and will not result in unnecessary, un-productive night outs & escalations.

In addition to these categories of issues, we will always face issues related to Non-functional requirements like Performance, Security etc. Those issues will surface only under certain architecturally significant scenarios & special conditions. That too, they will bubble only on the final stage of testing & deployment.

Sunday, September 27, 2009


For decades, XML remained as the only choice of communication / data transformation across layers in any applications that are architected based on services. It opened doors for many possibilities like inter-operable communications across different platforms. With the maturity of the platforms & products, average XML message size bloated because of lots of metadata & info related to security, transaction etc. The structure of XML is simple, elegant & human readable. But for consumers like applications codes, it is not a must for a communication mechanism to be human readable.

With the no. of applications using AJAX is increasing, especially in the case of RIAs, JSON replaced XML as the primary choice. This is becoming significant with applications shifting from SOAP-RPC to Restful services.

Why JSON is becoming so important:

• JSON can be easily handled by the AJAX / JavaScript clients than XML
• It is more lightweight than XML & hence high performing

Friday, September 4, 2009


It is common that whenever we talk about SOA, immedietly our discussion will jump into web services, SOAP, WS-* etc. In fact, for many of the techies, SOA mean SOAP and web services. They very rarely give due weighatge to the business side of it. Interestingly, in the recent days more awareness about significance of HTTP in SOA is growing and hence it resulted in more adoption of RESTful services for service enabling applications & business logic than sticking to SOAP/RPC web services. The XML metadata information and SOAP headers associated with webservices are considered to be an overhead than the HTTP headers. When HTTP itself is providing all facilities for an efficient, secured consumption of business logic & data, contractual SOAP web services is loosing its position as a key technology option for enabling services. It is witnessed by the fact that key players in the web like Google, Amazon, Digg, Flickr & Twitter are exposing RESTful services.

Plain Old XML (POX) and Java Script Object Notion (JSON) are the key data formats available from RESTful services. When it comes for data consumption by a machine or application code, JSON is preferrred option over POX because of its smaller foot print. It is also the preferred option for consumption by AJAX applications.

From the development perspective, in Microsoft.Net platform, multiple options are available for developing RESTful services. Either we can leverage Windows Communication Foundation (WCF) or ASP.NET MVC.

So in future, whether we will service enable our applications only through RESTful services or SOAP web services will still exist? We should wait and see.

Tuesday, August 25, 2009

Integration without ESB

Because of unstructured / unplanned development over the years, we have problems because of point-to-point integration between software applications, tight coupling at those integration points, lots of code and fewer configurations.

Based on the no. of applications integrating, no. of integration points will increase. If we have point-to-point integration in all these integration points , the we will have problem in the similar magnitude.

Initially to overcome the problems of Point-To-Point integration, we had Hub & Spoke. It means Integration based on Messages. That is , a Message Broker like MSMQ is used. Different applications connect with each other through Message broker by sending messages. The problem that was encountered here was the single point of failure and also the high volume message handling capability of the Queue become a concern.

Then came the services based integration where SOA played a major role. This type of integration becomes significant especially when there is a need to integrate applications across heterogeneous platforms. Because, there interoperability is the key requirement. ESB played a key role in these types of architectures.

ESB is primarily used for :

1. Schema Transformation / Data Transformation : To Transform Data or Schema of the messages that it sends / receives

2. Intelligent Routing: To intelligently route messages to various service end points depending upon the content of those messages.

3. Service Aggregation: To act as a Fa├žade and make a series of web service calls as a single service. This is based on the pattern “Service Aggregation”. It may also include some conditional logic that defines which of the lower-level web services are called and in which order they are invoked.

4. Load Balancing: To load balance the service requests across different service end points. It may have the provision that at the time of registering a business service, we can specify the list of service end points, which can be changed later by adding or removing end points. Here it provides a layer of abstraction between service client & service provider.

5. Enforcing Security: centralized, standardized security management through security policy framework.

6. Service Management / Monitoring / Logging: Proactive / Reactive monitoring of the services performance.

With the platform vendors are maturing towards offering products that are compatible with the industry standards [especially WS-* like WS-ReliableMessaging ], ESB is gradually loosing it's position in the integration arena !

Saturday, August 15, 2009

Enterprise Agility = Enterprise Asset!

Enterprise Agility – The capability of an Enterprise to respond to the changing market demands in a short span of time, cost effectively. Cost effectiveness is becoming significant in the days where IT is subjected for demands to optimize its operating cost. For an enterprise to accomadate changes cost effectively, it should have built its systems based on pluggable architectures and other elements that ensure agility.

Consider two enterprises A and B. Say for EnterpriseA, for every change it’s should make, it will cost $1000. For EnterpriseB, it is zero dollars. Say for example, every year 10 changes are to be made. For EnterpriseA, it will need $10,000. For EnterpriseB, it will be zero. This $10,000 saving for the EnterpriseB can be considered as an asset!

One dollar saving = One dollar earning!!

Tuesday, August 11, 2009

Domain Model based approach for "Agile" Systems

  • Basically, the imperative to go for either SOA or BPM or BRM based solutions are to keep the systems agile, responsive to the changes in the business.

  • There are multiple factors that could impact either Business Rules or Business logics like market conditions, reulatory requirements etc. To insulate the systems from the consequences of those changes, they are built to have loose coupling

  • Loose coupling is achieved through different techniques. Service enabling a system assure loose coupling for which systems are built based on SOA. Declarative business rules through BRMs or dynamic business processess through BPM systems are other available techniques.

  • Extracting out the business rules from the application logic through BRM is another technique.

  • An addition to SOA/BPM/BRM based approaches, one of the available approach that will bring “Agility” as a default capability to a system is “Domain Model” based development.

  • In the cases where behaviours of the business is subject to lot of changes, having a domain model will decrease total cost of those changes. Having all the behaviours of business (that is likely to change) encapsulated in a single part of the software (domain model) decreases the amount of time we need to perform the change because it all will be performed at one place. This will avoid duplication of business logic / business rule.

Friday, July 10, 2009

Android - a snapshot

Recently , I had a chance to explore Android (as an interesting hobby :)). That exploration resulted in this snapshot:

# Platform

• Android is an open source software stack – It includes: OS, Middleware, Key applications, API libraries for writing mobile applications

• Android supports most of Java platform except AWT & Swing

• Following things makes up Android :

o A hardware reference design that describes the capabilities required for any mobile device to support the software stack

o A Linux OS Kernel 2.6 that provides low level interface (device drivers)
o Open source libraries for app. development including SQLite, WebKit, OpenGL & a media manager

o A runtime to execute & host Android applications including Dalvik virtual machine (Android’s own optimized JVM)

o An app. framework

o An UI framework to host & launch applications

o Pre-installed applications

o A SDK with tools, plug-ins & documentation

• Android phones will comes with pre-installed applications that include :

o A Gmail compatible email client but not limited to
o A SMS management application
o A full PIM suite
o A fully featured Google Maps application
o A webkit based mobile browser
o An instant messaging client
o A music player and picture viewer
o The Android Marketplace client for downloading thied-party Android applications.
o The Amazon MP3 store client for purchasing DRM free music.

• APIs allows access to hardware access, location based services, support for background services, map-based devices, relational databases, interdevice peer-to-peer messaging, 2D/3D graphics

• Windows Mobile & Apple’s iPhone are based on proprietory OS; Android offers an open development environment built on open source Linux kernel

• It is supported by Open Handset Alliance and designed to run on any handset that meets the requirements

• Central feature of Android is that one application can make use of the elements of the other application. For this happen, Android applications will not have a single entry point for every thing in the application.

• Intents, Activities, Views, Service, BroadcastReceiver, ContentProvider – important things in Android development – Activitie & View objects are Front end – Intents & Services are Back end



# Building Blocks

•INTENTS - Intent is a break through concept behind Android – Applications expresses it’s Intents to Android platform & it will take care delegating it to an appropriate application. By that way, we can re-use the existing applications. –An Intent is Android’s method for relaying certain info from one Activity to another activity – It is the message passed between the Activities - When an Activity sends an Intent to Android Intent Resolver, it will look for the matching Activity and calls that Activity – The 3 core components of an application: activities, services & broadcast receivers are activated through the messages called “intents”. - Intent Messaging is a facility for late runtime binding of the components within a same application or different applications. – Android owns the responsibility of finding the appropriate activity, service or set of Broadcast receivers to respond to an Intent, instantiating them if necessary.

An Intent receipient can be a Activity, Service or a BroadcastReceiver.

Intent Object – It is a bundle of information – It contains:

1.Information of interest to the component that receives the intent (Action to be taken / Data to act on)

2.Information of interest to Android system (like Category of compoent that should handle it, instrtuctions on how to launch the target activity).
Basically it will have

A.Component name – Name of the component that should handle the intent. If
not specified, then Android will use “Intent Resolution” to identify the

B.Action – Name of the action to be performed

C.Data & MIME type of Data


E.Extras – Key-value pairs for additional info that should be delivered to
the hanlding component


There are two types of Intents:

o Activity Action Intents

Intents used to call the Activities outside our application. Only one Activity can handle that Intent

o Broadcast Intents

Intents that will be handled by Multiple Activities

There are some pre-defined set of Intents under these 2 categories


Intent Resolution

From another perspective, Intents are classified into 2 categories: Explicit & Implicit

Explicit – Component name is specified – used to call the activities within the application

Implicit – No target component name specified – Used mainly to activate the components in other applications

# If a component does not have any intent filter, it can receive only explicit intents. A component with filters can receive both explicit & implicit intents.

Intent Resolution rules:

1. If the action is not specified in the IntentFilter, it will then match any action coming from an Intent

2. An IntentFilter can have additional categories beyond what an Intent specifies to match, but must have at least what the Intent specifies. an IntentFilter with no categories will only match an Intent with no categories

So first, action and category specifications have to be a match. It’s important to understand that data is optional. You can work with action and category alone

3. If scheme is present and type is NOT present, Intents with any type will match
4. If type is present and scheme is NOT present, Intents with any scheme will match
5. If neither scheme or type are present, only Intents with neither scheme or type will match
6. If an authority is specified, a scheme must also be specified
7. If a path is specified, a scheme and authority must also be specified

Intent Filters

Activities, Services & Broadcast Receivers should have one or more intent filters to inform the system on which implict intents they can handle. Explict intent will be always delivered to target, irrespective of what it contains. Filter is not consulted. Implicit intent is delivered to a component only if it can pass through one of the component’s filters.

Intent Filters are available in AndroidManifest.xml



•ACTIVITIES – It is anologous to a screen. It will have View objects (Basically a View refers a control / field in a screen) – Most of the code that we write for Android will run in the context of an Activity - When an Activity is not actively running, it will be killed by the OS to conserve the memory – An application can have multiple Activities. - Life cycle method of an activity:

OnCreate, OnStart, OnRestart, OnResume, OnPause, OnStop, OnDestroy

An Activity started with StartActivity will become independent and will not send any feedback to parent. Activities started with startActivityForResult can trigger event in parent activity.

We can get result from a sub activity by calling setResult method. The intent that is returned can have URI and other extra info.


•SERVICES – Analogous to daemons / windows services – They will always run in the background until the handset is switched off – usually they will not have UI. They are of 2 types : Local service & Remote service

A Service is intended to serve 2 purposes: Running a background task or exposing a remotable object for inter-process communication.


•BROADCAST RECEIVERS – They respond to requests for service from another application – An Activity or Service provides access to other applications for its functionality through Intent Receivers. The requesting activity will leave it to Android framework to figure out which application should receive it & which should act on it.

•They can register either for global events or for intents.
•We cannot perform Asynchronous operations within BroadcastReceiver
•We can only start a Service. We cannot Bind a Service
•onReceive handler must be completed within 5 seconds
•Typically they are meant for updating content, launching services, updating an UI activity, make notifications using Notification manager
•Actually when broadcasting intents, the same Intent concept is used. Only difference is it is happening in the background. Also, a Broadcasted Intent cannot call an Activity. An Activity can be called only through a Broadcast receiver.


•CONTENT PROVIDERS – Android allows exposing data sources through a REST like abstraction called “Content Provider”. They provide a layer of Abstraction on a data source. These are created to share Data with other services / activities. A content provider uses URI to fullfill the requests for data from other activities. The Activities / Services may not even know which Content Provider they are using. When an Activity / Service issues a request against a URI, the OS will look for the applications that are registered against that URI and activites it. If more than one application registered against a particular URI, OS will ask user to choose the content provider. ContentProvider is used to shared data b between different application

•Content Providers exhibits characterictics of web services. Output of the URL of the content provider is not a typed data

•URI calls to content providers returns cursor

•Planning for a content provider involves: Planning for Database, URI, column names,; Extend from ContentProvider ; Implement query, insert, update, delete & getType methods; Register provider in the manifest file.

•RESOURCES – They are used to accommodate values which can be change later without re-deploying the application. Ex: XML files, Strings, Colors, Bitmaps etc. This info will be updated in the R.Java file. Irrespective of the no. of resource files, there will be only one R.Java file.

Different resource types are: String,Color,Dimention,Image,Color Drawable,XML Files,Raw Resources,Raw Assets, Layout.

Intents & URIs allows Android to provide Flexibility / loose coupling.

•Three types of components can register to be a Intent Handler. They are : Activities, BroadcastReceiver & Services.

•The elements of Intent are: Action, Data, Category, Type, and Component & Extras.

•Android SDK uses XML extensively to define UI layouts. All XML files are compiled to binary files, before they are placed in the device.



Different options available to store & retrieve data are: Preferences, Files, SQLite & Network

Shared Preferences : For storing UI state, user preferences / application settings, key-value pairs

Files : can be from internal / external media

Content Provider : for sharing data