EA - Enterprise Architecture in Action

- Amit Jnagal, Senior Technical Architect, Infosys

In my previous post, I talked about Henry Fonda's role in 12 Angry Men and the lessons it held for an Enterprise Architect. Let us switch from Hollywood to Bollywood. Consider the movie Lagaan (Year of Release: 2001; Director: Ashutosh Gowarikar; Our Architect: Bhuwan, played by Aamir Khan; Architect's character: Peasant, captain of a novice cricket team).

Lagaan highlights some aspects of an Architect's job - selling ideas, negotiation, leading change etc.

The movie ‘Lagaan’ will always be remembered for having made it to the Oscars from India and being one of the most successful Indian movies of recent times. The word ‘Lagaan’ translates to Tax that the British Government used to collect, from Indian peasants & Kings alike, during their rule. The movie depicts the struggle of a man who is offered a tax release package if he can beat the English at the game of cricket. The only problem is that neither he nor anyone else that he knows understands or has ever played the game. He is given three months time to learn the game, convince others, form a team and beat the English team.

The lessons that an architect can learn from this movie are:
•    Selling ideas & on boarding people
•    Never lose sight of the goal even in turmoil
•    Negotiation
•    Leading change
•    Asking for help
•    Overcoming traditional barriers
•    Having & maintaining faith
•    Courage under fire

Scenes to watch for:
1. In the first half of the movie there is a scene where our architect is thrown the challenge of beating the English at the game. He does not react immediately and waits for the opponent to raise the stake from one year’s tax break for one village to three years tax break for the whole province.

Nothing has taught me to do my due diligence more than this scene from this movie. As an architect you need to know when is the stake good enough to take a risk or walk away. Walking away is extremely difficult for most of us but sometimes it just makes common sense!

2. There is another very interesting scene during the beginning of the match between the two teams.  Since our architect’s team has never played the game of this scale before, they fret when the match starts. Irrespective of the direction of any shot being hit, everyone on the field starts running towards the ball. Till the time the architect instructs everyone to hold their ground and purpose and only pursue shots that are fired in their direction.

I have personally experienced this problem in large scale projects. The team totally loses control from top to bottom when a small issues comes in a high risk, high stakes project. It is at times like these that the architect should preserve common sense and pacify his team. Make sure the issues are tackled in the same way that they are tackled in a medium scale project. He needs to keep panic at bay and maintain order in the functioning of the team.

3. There is another scene shot on the immediate next day after the challenge is accepted by our architect. He still does not have any other player in his team and is looking for recruitment. The approach that he uses is same as that used by Napoleon when he had to get his army across the Alps - by convincing the army that this was in fact not the Alps, but just another mountain. In the movie, our architect ridicules the game of cricket by comparing it with a simple game of stick & peg which everyone is comfortable with. He gets a child to take the bowl and tries to hit it hard with a home-made bat. The setting that he chooses is the village center to get maximum effect.

This scene can teach an architect attributes like idea selling, on-boarding people & leading change. It also gives good insight into how to handle new technology and get your team up to speed. People who have seen this movie will also agree with another lesson that comes from this episode – help can come from unexpected quarters. The first team mate that our architect gathers is a mad fortune teller whom most of the village has written off as a no good, cynic.

4. While the team is practicing for the big day and they are still short of players our architect stumbles upon a hidden talented spin bowler. The problem is that he is an untouchable belonging to a lower caste and none of the other players want to play with him. The way our architect tackles this problem in the movie is by first embracing the new bowler and then reminding everyone of the common goal and common enemy. He also makes it crystal clear that this is not just a game and there is no one in the team whose ego is bigger than the goal. Later in the movie, this decision turns out to be a match winner where this same bowler walks away with the hat-trick.

The corollary on our side is not too hard to imagine. Working with big teams, all of us come across people whose egos sometime wears bigger shoes than their own. It becomes the job of an architect to herd everyone as a team and lead them to a common goal. It also teaches us how to overcome traditions and barriers that they impose.

5. One last scene that I would like to mention is in the last 30 minutes of the movie. The team finds out that one of them has been cheating in the game with the intention of making them lose for his personal gains. As soon as this truth surfaces, the immediate reaction from everyone is to kill that person in utter rage. Everyone besides our architect, that is. He knows that in this last hour, he cannot afford to lose out one player and go to play with one player short. His best bet is to make sure that this person turns around and plays his heart out in the next day’s play. After saving him from the rage of the crowd, he explains him how this is his last chance and how he would need to prove himself in order to stay alive. This gamble pays off handsomely the next day when that person plays instrumental role in clinching a crucial wicket.

The lesson that we architects can take from this particular scene is to never lose sight of the big goal, even under pressure or turmoil. It also teaches us about second chances and the process of renegotiating trust.

Posted by Guest Author at 6:02 AM | Permalink | Comments (2) | TrackBacks (0)

XML Appliances- Advanced Features

In my previous blog- I discussed the basic capabilities of XML appliances. In this and subsequent blogs, I  plan to discuss the advanced features of XML Appliances: Field Level Fine Grained Security, Rule Based XML validation, XML to HTML transformation, XML to WML transformation and XML to XML transformation.  In this blog entry, I will discuss only Fine Grain entitlements, and discuss other aspects mentioned above  in a subsequent blog entry. 

Fine grain entitlements for XML

           XML Appliances can provide fine grained security for enterprise data available in XML format.

A Customer Record could for example be split into four parts based on entitlement based on role:

• Sales Representatives can see Customer Record including internal discussions
• Account managers can see, notes made during Sales Calls including details of clients organization
• Support  Engineers can see technical details of past purchases by the client
• Accountants can see details such as credit limit as well as credit rating of the customer.

The entire customer record could be represented as a XML document, which is secured using fine grained role based entitlements.  The standard used to describe the fine grained security-XACML-is described in an informative tutorial  

The processing of role based security can be very CPU intensive. A XML appliance can process role based fine grained entitlements in a cost effective manner.

XML data so secured could be made available to portals such as WebCenter 2.0 from Oracle.  It could also be used to create HTML using XSLT transformation. For PC and mobile clients, with the CPU capacity, this transformation can be done on the client. For other clients.with limited CPU processing capbility, the XML appliance itself can perform this transformation.

Posted by Kevin Apte at 6:10 PM | Permalink | Comments (0) | TrackBacks (0)

SOA applicability is very dependent on an organization's environment. Recently I got into a discussion about "SOA in the small." Is it feasible? I think not. But IMHO elements of SOA can be applied to the organization to fit into an enterprise SOA roadmap

This discussion reminded me of a couple of presentations I had made at a couple of conferences. I have combined these into a slideware presentation.

| View | Upload your own

The fable of "The Six Blind Men and the Elephant" comes to mind. Stakeholders investing in SOA need to see benefits that are relevant to each and every one of them. Otherwise, you start losing the investors. Each stakeholder has a different view of SOA. I dub the the entire SOA landscape the "Service Oriented Elephant."

Your perspective of SOA will be depend on which end (or side) of the Service Oriented Elephant you end up at. But don't forget that in the end, there has to be an elephant for the parts (tail, tusks, ears, legs, side, or trunk) to make any sense. Similarly, there has to be comprehensive view of the "Service Oriented Enterprise" for any investment in SOA. You don't have to do it all, but there has to be an "all."

Posted by Ajit Sagar at 2:52 PM | Permalink | Comments (0) | TrackBacks (0)

- Amit Jnagal, Senior Technical Architect, Infosys

None of us are new to the entertainment value of movies. They can make us laugh, cry, ponder, put us to sleep, wake us up and can entertain. The use of movies for the purpose of education is not new either. In fact, there is a special genre of movies with educational values, meant for different audiences.

Recently, I was in a discussion with my mentor. We started talking about challenges faced by the new age architects. Gradually, the conversation drifted from these challenges to the amazing world of movies. Soon after that conversation, I was conducting some training sessions for budding architects. The opening act for this training was titled – ‘The Role of an Enterprise Architect’.  While preparing for that workshop, I related it back to the conversation about movies and what lessons can we architects learn from them

Movies (from Hollywood & Bollywood) can offer good lessons to architects and in general provide a good overview about role of an architect.

Let us consider 12 Angry Men (Year of Release:1957; Director: Sidney Lumet; Our Architect: Juror#8 played by Henry Fonda; Architect's character: Juror in a 12 member Jury

It would be highly in-appropriate if I tried to relate the role of an Architect to characters in movies and started with any other movie. 12 Angry Men is a black and white movie which depicts a murder trial for which a jury of 12 members is to deliberate and come up with a decision.

At the start of the deliberation, 11 of the members are convinced that the defendant is guilty of murder in the first degree and one person, only one person is doubtful. For the next one hour, this single gentleman convinces everyone else of the loopholes in the case and gets a 12-0 verdict acquitting the accused of all charges.

Incidentally, this 12th person who single handedly turns the opinion around happens to be an Architect by profession (a civil one though).

The lessons that an architect can learn from this movie are:
•    Consensus Building
•    How to speak your mind and not go with the general opinion when you are not convinced
•    How to use facts to justify your argument when emotions run high
•    Innovation
•    Never, ever to let go of your common sense

Scenes to watch out for:

• There is a scene in the middle of the movie about a fact presented in the case according to which it takes less than 10 seconds for an injured person to walk about 20 meters. Our architect proves, by enacting the situation, that it is not possible.

I can very easily relate to this situation in architecture work. A lot of time people come to the negotiation table with pre-conceived notions or facts that they believe to be true. If you doubt the authenticity of a fact, go ahead and challenge it. Do some research, collect facts and go back to the table with figures and numbers. It can help you turn the balance to your advantage. The other aspect of our work that this scene highlights is the need and importance of PoC’s to validate hypothesis and bring certainty in projects.

• Towards the beginning of the movie, there is a scene where the jury talks about a witness who remembers the accused carrying the same knife with which the murder was committed. The architect produces an exactly similar looking knife that he purchased after hearing the argument. He proves that the knife is not extra ordinary and is very easy to get hold of. This shows the importance of doing your homework or research on a project.

This scene again emphasis the value of research and doing your homework. Before going for a discussion, you can find new insights if you spend some time with Google or an expert that you trust. It also teaches us architects to look beyond what the eye can see. Sometimes, the facts are not what they seem.

Posted by Guest Author at 8:54 AM | Permalink | Comments (0) | TrackBacks (0)

Wow, is the only way to start looking at the turnout in Orlando for the Gartner Enterprise Architecture (EA) Summit held last week (June  11 - 13). More so since all the participants braved the thunderstorms and weather to show up despite stranded flights. For myself, I decided to take matters into my own hands after an unscheduled landing in Tampa and drove down enjoying Florida’s wide lane freeways which seemed surprisingly dry given the stormy weather hours ago.

Back to the EA conference which mostly starred Gartner VPs and Analysts, the whole conference was about Business Architecture (BA), EBA, SOA and Information Architecture.

There was an over bearing importance on Business Architecture and managing the goals of the organization and hence the CEO.

One area which keeps beating us is the missing steps between the as-is to to-be systems. Especially rationalization of systems and the specific options to “simplify” the underlying assets without making systems overly complex as we add BA, BPM, SOA into the mix.

The turnout as mentioned in the Gartner opening by Anne Lapkin (Research VP, Gartner), had an extended industry presence from manufacturing, services industry and telcos besides the regular financial services, retail and insurance segment. While the turnout was huge, we still missed the CIOs in the audience.

Does this mean the CIOs and CTOs relate less to EA? Given the magnifying glass business sponsors have on IT budgets and its alignment to strategic corporate initiatives, EA, information architecture, security are topics getting into the hot seat.

Posted by Sohrab Kakalia at 4:21 AM | Permalink | Comments (0) | TrackBacks (0)

The Eisenhower System was envisioned as a systematic, incrementally adoptable plan for surface transport for the United States, which has been in build and operation for around 50 years. It acts as the fundamental artery of passenger and goods transport across United States.

When we study the history and operation of the Eisenhower System (a.k.a The Dwight D. Eisenhower National System of Interstate and Defense Highways | http://www.fhwa.dot.gov/reports/routefinder/), we will find many parallels to the information superhighway of the Enterprise, the Service Bus, such as

• Provided standardizations in naming, construction and operation, routing, governance (ownership, leadership, responsibility) and so on.
• Sequential signage to easily plan and navigate through the routes
• Had been lobbied for by major U.S. automobile manufacturers (as per Wikipedia)
• Made a dramatic changes to existing routes, neighborhoods and associated cities (as described in Divided Highways, http://www.skidmore.edu/academics/roads/index.html or as we watched in the pixar movie ‘Cars’)
• So many urban legends e.g. one out of every five miles of the Interstate Highway System must be built straight and flat so as to be usable by aircraft during times of war; this is not true.

When I find that the product vendors are pushing the enterprise IT for ESB adoption, where IT managers do not know what to do with existing message queue or EAI investments, it is very similar to the 50 years of the Eisenhower system. The current system owners are afraid that they would need to give away many of their exiting processing capabilities for cheaper sourced processing capabilities, interconnected through the super highway. Meanwhile, the architects are marching with their big SOA roadmaps and plans to construct new adapters, services and composites (=exits, entrances, interchanges, bridges and routes), where they debate and argue about the intricacies of service naming, bundling and so on. The enterprise governance officials (=bureaucrats, senators and congressmen) are deep in their discussion on funding, leadership, ownership and contracting, where there are many business driven exceptions (=one of the congressmen want to change the route to include his consistency). 

So let me propose to all the SOA enthusiasts – Folks, we should study the 50 years of The Eisenhower System; it should be handy to build our new Service Bus driven IT enterprise Architecture.

Posted by Binooj Purayath at 6:26 PM | Permalink | Comments (1) | TrackBacks (0)

We are continuously striving to represent the software concepts in such a way so that we can easily relate them to the real world entities and activities. IT provided automation and tools to create and facilitate a better business environment. Along this journey somewhere the solution (IT) to solve the business problems itself became a problem due to the complexities it created, which paved the way for creating new approaches to solve the business problems. The journey showed us the various styles of software representations and highlighted the differences in thought process in creating the software.

The various styles or architecture approaches so far being used are

• Procedural oriented architecture
• Object oriented architecture
• Service oriented architecture
• Resource oriented architecture

Procedural orientation provided the early automation but created complexities due to the separation of data and operations. Object orientation encapsulated the data and operations (methods) and moved us closer to the real world entities and simplified the programming model. Service orientation moved us even closer to the real world by aligning us to the business processes. The fundamental difference between object orientation and service orientation as I see it is the data vs. process emphasis. Object orientation approaches from the data entities point of view where it creates the objects which can encapsulate the data and methods related to that entity or object. Service orientation approached from the process point of view which encapsulated a process or a number of processes along with the entities participating in that process/s. Resource oriented approach is still evolving and is largely based on the concept of the World Wide Web. Everything that can represent itself and can be addressed by a request is treated as a ‘resource’. Unlike the object a resource does not have a state. Each state of the object itself can be represented as a resource.

There are multiple pros and cons of each of these architecture styles. These architecture styles can co-reside while addressing a business problem. It’s important to have the right business orientation rather than being religious about object or service or resource orientation. In my view, Business Oriented Architecture should be the right orientation and need to be adopted as a guiding principle while providing the IT solution to address the business problem.

Posted by Shreyas J. Kamat at 5:15 PM | Permalink | Comments (1) | TrackBacks (0)

One of the lead Butler Group analysts went on to explain how one can't necessarily do one without the other, especially if we are looking at a business transformation context.  Incidentally, he coined the term ‘Service Oriented Enterprise Architecture’ too, which naturally put a smile on my face as a colleague and I wrote a paper on the missing link between EA and SOA last year. We presented it at the Deutsche Post SOA Days Conference held in Bonn, Germany (this is the pre-eminent SOA conference held in the ASG region).

So, it's good to know that the industry is heading in the same direction.  We need to do a much better job with enterprise IT architecture before going the whole hog into the architecture of an enterprise.  Today, we are still unable to effectively define an execution platform to support a business operating model.  I have also been a fan of learning to walk before one runs!  So, let's get the operating model defined and ensure that we collectively define and model the 4 dimensions of EA for that operating model in a consistent, repeatable and manageable fashion.

The presentation: 

| View | Upload your own

Posted by Sohel Aziz at 8:25 AM | Permalink | Comments (0) | TrackBacks (0)

Provisioning of Cloud infrastructure via services, be it storage, or compute power, or utility services, or even business services, is a great idea. However the very notion of usage of XML based Web Services (or even REST based services), over the web, to deliver on this vision of Infrastructural SOA with leverage of multiple infra services from multiple providers to create an enterprise app, as close to enterprise ready as possible, is ridden with its own set of issues, primarily stemming from the NFRs (non functional requirements in SOA)..

1. In distributed application development leveraging these cloud infra services, how is security handled in a robust manner?

2. Like in traditional in house hosted apps, will such federated infra be able to provide the requisite reliability (and availability - think 99.999 % for enterprise ready).

3. issues related to Data management, XML management, distributed synchronization models, transacation models, etc. is a huge area of gap to really address enterprise readiness..

we can go on and on..

This is a clarion call to create a research vision for such federated futuristic vision of zero in-house intra enteprise infra, leveraging best of breed infra services from the cloud via standards based SOA..There is a need for SOA researchers and grid community and the data base community to address this...

Posted by Dr. Srinivas Padmanabhuni at 7:09 AM | Permalink | Comments (4) | TrackBacks (0)

As SOA initiatives mature, the number and size of XML messages starts growing rapidly. The total XML traffic can therefore  grow exponentially. Elegant architectural design principles, such as canonical models, and model driven architecture,  require processing large XML payloads. Assuring good performance at reasonable cost, while maintaining SLAs can become challenging.  XML Appliances address this issue, and are maturing into a hardware/appliance based replacement for ESB.

XML Appliances address this problem by providing a low latency scalable and performant way of processing XML messages. XML appliance features may be classifiedas "Basic" and "Advanced"

Basic features include: Encryption, Compression and Schema Validation. These features have been used extensively for 5 or more years, and are well established in the industry.

Advanced features include:

• Rules based validation using XPath and XSLT- messages that do not meet validation rules can be automatically rejected.
• XPath based search
• XML to XML transformation through XSLT
• Rules based validation using XPath/XSLT- Invalid documents can simply be rejected.
• XML to HTML transformation using XSLT
• XML Content based routing
• Conversion from flat files and legacy formats to XML(This feature seems to be available only in DataPower.)

Basic  features such as schema validation, compression and Encryption have been benchmarked at hundreds of megabytes per second.  It is a no-brainer to use XML appliances in this situation.

On the other hand, with advanced features, XML appliances run a lot slower. The speed at which XPath searches and XSLT transformation seems to depend on the complexity of the XML document, and the parsing task at hand. An aggregate XML message that simply aggregates hundreds of messages may be parsed very fast. But a XSLT transformation that does arithmetic calculations and complex transformation will run slower, typically 1-10 MegaBytes per second.

XSLT/XPath based transformations cannot replace work done in procedural languages such as C# and Java. Complex financial calculations, for example, or a validation that depend on other database systems or web services, must be done in C# or Java.

The claim that these appliances can replace an ESB seems farfetched. Intel has a Google campaign, that goes: Still using Tibco-Swith to Intel XML Appliance.(They repeat the campaign with other ESB vendors. )  ESB provides numerous features such as Protocol Mediation, Applying Business Rules, Assuring connectivity between Java and .net systems. It could be argued however, that the XML transformation, which can be a large part of the CPU usage of an ESB  can be offloaded partially/completely to an appliance.

XML Appliances provide performance benefit, as well as the benefit of lower latency.

The other advantage of the appliance is consistency of speed. Unlike a J2EE server that may underperform periodically due to other applications, or due to Garbage collection, an XML appliance performs at consistent speed.

The fully loaded cost of a J2EE or Portal Server can approach 100,000 dollars or more. Using this server for XML Transformations that can be done on lower cost XML appliances, is wasteful.

Skillfully integrating XML appliances with your ESB, Messaging and Application servers may provide critical performance benefits to your SOA initiative. It also changes the debate about the feasibility of using XML for intra and inter-enterprise integration.

In future posts, I hope to elaborate on integration of fine grained and rule based security using a XML Appliance, Deciding when to use XSLT/XPath, and integrating the appliance into the messaging and ESB infrastructure.

Posted by Kevin Apte at 10:30 PM | Permalink | Comments (2) | TrackBacks (0)

- Mohan Babu K (cross posted from the Managing Offshore IT blog)

Many of my peers enjoy the privilege of being trusted advisors to clients we work with, though I guess this comes with a lot of responsibility too. I use the phrase with caution since in our industry misuse of terminologies are rampant. In a sense, the term ‘trusted advisor’ is akin to another concept of ‘thought leader:’ every technologist and consultant worth her/his salt wants to be in that position though many don’t have a clue of what it takes to be one, or even to continue down the path when closer to that utopian goal.

Case in point, I am on the road this week, traveling with a client team that is embarking on a large integration [SOA] initiative. As is to be expected, they have floated Request for Information (RFI) to software platform vendors and are in the process of continuing down a deeper technical evaluation.

Since an existing Infosys team is already engaged with the client in the application development space, they looked to us for advisory assistance during this exercise. The request came at extremely short notice and we managed to quickly put together a team to for required support to the client and I offered to join them in person. A few interesting aspects jumped out during the exercise:

• We traveled to two large software vendors headquartered in the West Coast - that I shall not name for obvious reasons – where the vendors put together a series of secessions that included the usual Dog and Pony show along with sessions that were more customized deep-dives with their internal product experts
•  The client was already aware that we had expertise in the platforms and the fact that we were also tier-1 alliance partners to the vendors being evaluated so the expectation was clear: be our trusted [read impartial] advisor in this engagement
• My team did factor in the yin-yang from our internal alliance management groups, each of which had an interest in positioning the specific vendor (alliance partner) for obvious reasons: the vendors were leaning on our alliance teams. 
• Another obvious dynamic that my team in this engagement has to watch out for: client’s projects are downstream work for service providers. But in our eagerness to get started on the work, we should not spur them towards a decision.

While the evaluation is proceeding as expected, my eye remains on the ball :: translating the results of this exercise and evaluation into a strategy that the client’s executives can propose to their stakeholders … which will then have to get projectized…. And will hopefully get executed using our Global Delivery model

The horses are just out of the gate, so it would be hard for me to even speculate on the direction of the evaluation; but stay tuned.

Ps: And in case you are wondering, client’s advisors don’t get the trinkets and t-shirts while accompanying them to the vendor’s company store. :-(

Posted by Guest Author at 8:53 AM | Permalink | Comments (0) | TrackBacks (0)

I have always thought of SOA & BPM as two complimentary solution approaches. There are numerous articles that talk about interplay and synergy between SOA & BPM, and this has become so obvious that any new article on this topic doesn’t even draw my attention. However I recently stumbled upon a blog post titled ‘Why BPM screws up SOA’ by Steve Jones that really caught my attention. I completely disagree with Steve ...

This is a rather long post. I apologize I couldn’t keep this short, as given the highly debatable subject I think I need go deep into this matter and put forward my views in detail

Posted by Dhiren Mehta at 7:15 PM | Permalink | Comments (2) | TrackBacks (0)

The SCA Java EE Integration Specification has been released. It is quite an interesting read. The vision of SCA is to build composites and composite applications out of configurable, reusable service components or assets as I had tried to explain earlier. It does not intend to replace existing open standards but to build over those standards to enable a technology agnostic service component integration platform. So it has support for multiple communication protocols (or binding types), component implementation languages (implementation types) and component interface languages (interface types). The list of these types is growing. Also I had mentioned (SCDL vs WSDL) the promise to support so many technologies in a standard manner is indeed a big one! This often gives rise to skepticism in some quarters and comparison with similar looking standards such as the JBI.

However, it is important to remember that in the world of SCA, the concept of service component (or simply services and not necessarily web services) is fundamental. An important aim or design goal of the set of SCA specifications is to enable exposure of existing software assets as service components having well defined, carefully designed and publicly visible interface definitions. This is also one of the important goals of service-orientation and SOA. The latest Java EE SCA Integration Specification re-instates that. It specifies how a given JAR/WAR/EAR (Java application / component archive) which has already been built (without having any SCA stuff in mind), could be converted into a first class service component (technically called an SCA contribution). So I can re-use my existing set of Java EE components (sorry only Java EE and not J2EE L) and convert them into service components to be used by others. Imagine a BPEL component talking to an EAR module directly! The specification also enables Java EE web modules to be exposed as SCA contributions and enables presentation components such as JSPs to directly consume SCA enhanced service components, bringing my dream of Portal Composites a step closer to reality.

To the discerning it may appear that there is a good amount of overlap (re-use) between this specification and the Java EE specifications and indeed I had to go back and forth on this specification to really understand its potential. But I find this overlap proper as the SCA is not trying to re-invent the wheel but map the critical features of existing platforms into the SCA, and at the same time ensuring that the final product is a simple uniform looking service component to be consumable by other platforms, enabling interoperability to a large extent.

Posted by Sudeep Mallick at 3:11 AM | Permalink | Comments (3) | TrackBacks (0)

Around the budgeting cycle at establshed clients, the three dreaded words "Statement of Work" loom around the corner. Why dreaded? Well, getting all the ducks in a row, tailoring the effort, resources, and cost to the ever-changing environment of the corporate world is always a big challenge. Interestingly, the basic principles of SOA can be readily applied to the preparation and publication of SOWs.

In fact, we have successfully done this at a client. In order to provide clarity around the work that we offer, the definition of services followed the same process as the definition of services in an enterprise system. Here is how it went. Before creating the SOW document, the following steps were to be followed:

•  At the start of this style of SOW management, discrete service groups were identified for each external vendor
• At the start of the budget allocation, all the "service leads" needed to define the services offered by their teams.
• The consumers of the service needed to be clearly listed
• The service definition needed a clear definition of SLAs and escalation channels
• The triggering business processes (for example, "application review") for each service level needed to be identified
• The processes affected by the service were clearly identified
• OLAs (Operational Level Agreements) were defined for processes on which the service was dependent.
• The duration of the service, the turnaround time, etc. were documented
• The links to the services were added to the documentation of the invoking business process
• Finally, the services resources were estimated and the SOW was created.

There you have it. An organizational, operational application of SOA principles. Actually, is it not the other way around? SOA is a discipline/concept that grew out of business processes and business services. Sometimes we forget that the chicken came before the egg (or the other way around :-))

Posted by Ajit Sagar at 2:40 PM | Permalink | Comments (0) | TrackBacks (0)