Skip to main content

Posts

Showing posts from 2009

SOA +

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. o…

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 stan…

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 working...in 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…

XML to JSON

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

RESTful SOA !

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…

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 th…

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!!

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 change…

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 tha…