Enterprise Architecture of the Future

Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

noreply@blogger.com (Unknown) — Mon, 22 Aug 2011 12:07:00 -0700

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural principle is considered in proposing architectural solutions. However, there is a distinct benefit to using both paradigms in unison in solving business problems!!

Business events are the "core concept" that drive any EDA implementation. On the other hand, decoupling business applications and the business functions/ business processes embedded in these business applications is the core theme of SOA. SOA implementations rely on the use of standards based web services technology stack and that of canonical business documents (XML) .

However, it is my contention that an enterprise that does not invest in the web services or ESB technology can still leverage EDA style business events to implement loosely coupled business services provided it makes an effort to analyze its' business events and creates canonical representations of these key business events. This could mean defining business events that encapsulate a business concept that have an associated business concept state indicator or a business action indicator. Further, these business events can be used to trigger constructs such as event handlers that act as a facade or layer of indirection to execute a business function via the use of an application API.

It must be noted that the terms event producers and event consumers or publishers/ subscribers are being used loosely to denote the initiator of the event and the owner of the business behavior that "knows" how to deal with the event. In a SOA realm this would be the service consumer and the service provider respectively.

The key to this model in leveraging SOA is the use of self-describing canonical business events that are subscribed to by independent event listeners. These event listeners and/or event handlers that are delegated to by these event listeners help insulate the event producers and event consumers from the complexity of knowing how to interpret the events. Here the event producers/ publishers and event consumers/ subscribers are decoupled from one another via the use of canonical business events as well as messaging technologies.

Either of the two layers i.e. the event publisher or event subscribers can be altered long as the contract is adhered to in terms of the canonical business events. Also, messaging technology oriented configuration consoles allow the definition of the event publisher/ subscribers to be connected via metadata as opposed to hard-wiring these in code. Event handlers act as event adapters in that these could translate the event and invoke the required API call to deal with the event. The event handlers act as a business facade that hide the workings of the business application and allows the business application to change without affecting the event producers.

To recap, if loose-coupling is a core SOA principle that promotes business agility then the use of event handlers invoked using messaging technology and canonical business events can be used to deliver this goal. The enterprise does not need to invest in a SOAP stack right away to achieve this goal. If desired technology standardization and interoperability can be introduced at a later phase by turning these event handlers into web services. This two phased approach defined above enables the enterprise in pushing off investment in the technology stack to a future phase without sacrificing business agility and/or offering novel business capabilities.

Please feel free to drop me a note.
thanks.
surekha -

Launching MDM as Part of Larger Initiatives

noreply@blogger.com (Unknown) — Tue, 9 Aug 2011 06:49:00 -0700

Let me walk through a situation that may be common in many organizations. You as an IT visionary recognize the need for MDM initiative but are having difficulty appropriating funding due to cost concerns or simply as a result of organizational inertia. You decide to ride the coat tail of another major initiative that is somewhat related to the successful implementation of the MDM. Is it a good idea? I would suggest yes, but be careful about setting expectations and having the right level of buy in or your successful execution of MDM initiative may be perceived as not so successful. This may happen due to personalities involved or not having MDM implementation risks included in your schedule or cost estimates. You can be sure that you are going to run into data issues, and amount of data you wil have to deal with will always be more than you think. All these issues may impact the larger intiative and will reflect badly on the MDM effort.

Make sure all stakeholders understand that while MDM is expected to support the larger initiative, it has its own benefits and its goals are much larger in scope. Also, include additional time and cost to mitigate the risks.

Ashok

Business Event Subscriber Responsibility?

noreply@blogger.com (Unknown) — Sat, 2 Jul 2011 14:36:00 -0700

Thought I would write a comment about what are some of the expectations of a business event subscriber. These would be rules that the business event publisher could depend on. These sets of rules form the basis for Event Driven Architecture (EDA) based implementations.

Subscribers of business events and business alert notifications often assume that the business event publisher is responsible for insuring that duplicate events and any repeat alert notifications are suppressed. However, to protect itself the subscriber has to be able to "analyze" the business event to determine if the erroneous event/ alert was sent by the business event provider, messaging architecture or the enterprise service gateway. The subscriber (business application, business process) would have to "know" when to discard the business event as being a duplicate event, as well as when to re-apply the same business event, which could have been issued as a result of change in the business policy or due to an increase in the business alert thresholds. Knowing when an event transmission is real versus a false notification insures that the outcome of the EDA implementations are valid.

For instance, if a "low inventory alert" is received by the Purchasing Process it may react to this alert notification by transmitting a PO to the supplier. However, if the same Purchasing Process gets a second alert a few seconds or a few minutes later chances are the Purchasing Process may choose to ignore this. Not examining the alert more closely may cause it to erroneously discard the alert. It is possible that in order to optimize and tune the response processing the subscription process just looks at the product and quantity to de-dup alerts received within a certain period thus causing the second alert to be discarded. The business impact of ignoring the second alert was failure to increase in the "minimum product level". The bottom line, the subscribing process has to know how to differentiate between fundamental business rule changes and duplicate alerts and not have a compute process optimization overrule business policies.

In general, in an event driven architecture realm the disconnectedness of the publisher/ subscriber pair places a burden on both parties to insure that there exists a mechanism and rules to enable "semantic" translation of the message payload that carries the business event or the business alert. Without investing in the definition and analysis of these semantics benefits of the loose coupling EDA architecture would deliver a scalable technical architecture model but would not yield the right business outcome.

It must be noted that standards such as WS Eventing, WS Base Notificaitons and WS Notification help to define WSDL and XML Schemas for defining the mechanics of loosely coupled and inter-operable EDA implementations but the business semantics and rules in constructing and consuming the events are not really well laid out. Not having had exposure to specifications such as ebXml and OAGIS business documents I assume some of the B2B interactions may have more mature semantic definition but for the most part I think these rules of engagement may still need to be fleshed out by the participating parties.

Thoughts and feedback on this topic would be very useful.
surekha -

Service granularity and service reuse - why information semantics are key?

noreply@blogger.com (Unknown) — Sun, 29 May 2011 11:11:00 -0700

In the following blog which refers to the Amazon CEO's "letter to the share holders" one is truly amazed to read about how the Amazon team constructs a single product detail page from a combination of 200 to 300 services!!

Amazon architects may have truly found a way to identify the right level of service granularity to combine these into composite service offerings - without causing the information in the combined service to be distorted. This so called semantic dissonance has led many of us architects to create coarse grained services which preserve the quality of information but at the cost of reuse!

This is the the balancing act of how to define a service with the right grain of information encapsulated in it such that once it is combined with another service the combined service is still able to deliver meaningful information at the same grain of the originally combined services. This is what we mean by semantics that govern how to combine two or more granular services to create a meaningful composite service which continues to encapsulate information that is valid and accurate. It may be technically possible to create a composite or a single course grained service starting from two granular services (long as the canonical models/ payload have common elements) but the combination may overlook key business constraints, business rules, regulations and algorithms that render the final response invalid and inaccurate.

A very simple example, combining product sales of a region with product marketing dollars to yield a service that delivers marketing efficacy may be a great new service concept. However, if the product sales service does not provide information about the tenure of the product company by region or the presence of similar competitor products by region then the marketing efficacy service is not able to account for lift in the sales accurately. The reason being marketing efficacy service cannot appropriately reflect the efficacy of the marketing dollar as being attributed to the "novelty" factor (where in the product is the first to enter the market in this region, or else if the product has a very attractive "entry price point" as it's debut to this new region). Both of these artificially show that the marketing campaign strategy is far more successful than it might really be. The price and novelty had more to do with the sales lift.

The use of information by the business to make strategic decisions and the study of information flow across lines of business and the alignment of business information to strategic business activities is key to business architecture. By extension we find that it is in the realm of business architecture to govern service interactions and the creation of composite strategies to guard against semantic dissonance.

Please share with me your thoughts.

surekha -

How to take a Transaction Based Vendor Relationship to the next level?

noreply@blogger.com (Unknown) — Sun, 29 May 2011 08:57:00 -0700

In the following blog, I talk about "What is the definition of a strategic partnership with a vendor?" and outline a few thoughts on how large enterprises should engage with their vendor partenes and what the expectations of such a relationship should be. A fellow blogger of mine expressed his "dissapointment" with vendor partners and their focus on selling new product as opposed to helping maximize the returns from the existing IT Assets.

I whole heartedly agree the pressure from vendors can be exasperating. I was thinking if there is a way to turn this around. What if as an example, your IT product vendor were told that they would have to provide expertise (at no cost) to solve current interoperability issues or resolve performance bottlenecks between their product and one other product while show casing a operations admin and management/ monitoring tool - OAM tool? This would be their elite product engineering or premium consulting service participating on-site mentoring your team and not the "support" organization which has to trouble shoot remotely.

Another example, if this is a package solution vendor with a long deployment cycle then the vendor can be asked to offer (again for free) analysis tools or processes or best practices and other accelerator kits that improve speed to market for their product, with the chance to demonstrate components of their next generation product. Again, the vendor has to part with IP (intellectual property) and address your pain point with the chance to demo a product that would or could be a fit in "your" enterprise.

The result would be the ability to extend or enhance the life of existing investments, while evaluating the vendor product, vendor processes and expertise in a real life scenario. Most importantly however, you are putting their resolve to test as to whether they are able to or willing to be your strategic partner and not just a transactions based product vendor.

Of course, I would be remiss in not stating that VMO, PMO and your legal departments would have to help with insuring this was a fair and scientific discovery process and also, that the licensing models were conducive to both parties.

As always your comments are welcome.

Surekha -

Should Architects aspire to be Product Managers?

noreply@blogger.com (Yogish Pai) — Tue, 5 Oct 2010 12:08:00 -0700

One of the interesting trends I am observing is that Architectures aspiring to be Product Managers. Have recently come across multiple PM who were architects and have also been approached my a few who are interested in becoming one.

Following are my thoughts on when Architects should consider PM as their career path.

A true Business Architect with the ability to map the technology strategy to align with the Business Strategy
Good understanding and hopefully first hand experience interacting with the real customer (not the business units)
Good understanding of revenue and business model
Passionate and believe about the role of the products in the customers life (whatever they are using the product for)
Ability to influence cross-functional team and get everyone passionate and focused on the product
Willing to change course mid-stream based on customer/market feedback
Ability to ride up and down the market roller coaster
Ability to keep singularly focused on an single product/portfolio

Do not take on the role:

by assuming that PM get to define the product and every one else will follow without any questions (the PM is responsible for bringing every one on board)
consider whether one would be a great Architect vs. a good Product Manager (focus on what one is better at doing - a great advise given to me by my manager)
do not want to deal with constant communication with customers / leadership teams
assume that the grass is greener there - doing what one does best shall reap the right rewards

Just my point of view and this could also apply for taking on a role of a Business Liaison in an IT organizations.

- Yogish

Enterprise Architecture (EA) team's role in Solution Delivery

noreply@blogger.com (Unknown) — Mon, 14 Jun 2010 08:25:00 -0700

Hello Fellow Architects - I am writing this blog in response to Todd Biske's blog entry on the fact that Enterprise Architecture Must Assist in Delivery. I am in complete agreement with Todd on this aspect of EA's role in the enterprise. Participating in delivery of business solutions is a value add that cannot be discounted. Not only does it add to the credibility to EA but it allows EA to be viewed as an ally which makes it easy for it to stay in touch with the "goings-on" in the enterprise. This partnership and visibility is key to start identifying cross-domain synergies and cross-business process impacts across all the granular projects.

As the leader of EA I have tried to instill this behavior in my team. My team is now seen as a much more "useful" partner by delivery and not just as a "watch-dog". Some of this perception change was a result of EA working with delivery in coming up with practical multi-step solutions/ alternatives to EA standards compliance. We reached out to the delivery teams that were under a severe time crunch to come up with Remedial Action plans that incorporated tolerable architecture compromises that would not jeopardize the stability and flexibility of the solution while still delivering business value (on-time!!). Putting such intermediate architecture solutions in place with hooks for building upon these architecture constructs increased buy-in from both application delivery teams and their business partners. The result the business partners got to test a more robust solution and were willing to give the project team adequate time in the next phase. In addition, we were "invited" to review plans for the next phase where we could inspect the program plans that included time to work on the agreed upon architecture compliance roadmap. I have to admit that EA did go down to a much more technical design level for helping with the integration and infrastructure to be able to communicate our architecture roadmap and recommendations.

EA achieved not just inclusion in the process but also this forced our architects to stay in touch with reality. This education for our Enterprise Architects allowed us to understand both limitations and constraints of the enterprise and also the technology. Learnings from this experience were then taken into consideration in refining the technical reference implementation for the EA strategy. Finally, this education has enabled EA to be a more formidable team that was able to bring this knowledge to evaluate vendor "marketecture" thus keeping irrelevant products out of the enterprise.

Your feedback is invaluable.

Thanks.

Surekha,

I have been busy developing globalized SaaS products

noreply@blogger.com (Yogish Pai) — Thu, 18 Feb 2010 20:09:00 -0800

It has been a while since I last blogged, especially after joining Intuit in 08-2008. For those not familiar with Intuit engineering culture, Intuit is one of the most admired companies above the other famous companies and can attest to that (feel free to drop me line if you want more details).

OK! enough about where I work and just a quick reminder to the readers of this blog - the comments on the blog represent my own personal view and not that of my employer or any third party (with disclaimer in place can now continue :) ).

For over a year now I have been working on a personal finance tool product called Intuit Money Manager which was launched last month in India through our partner Money Control - click here to learn more about the product and click here to get started with a 90 day free trial.

So what had this got to do with Strategic Use of Information Technology? Well! for those interested in managing your own money (like me) - we have been using tools like Quicken, Money (Microsoft withdrew the product from the market last year) and Mint.com which has been very useful in helping plan our finances.

Intuit Money Manager takes only few minutes for the consumers in India to get started and with capabilities like account aggregation, auto categorization, setting goals, reviewing trends (income & spending) and tracking investments provides a comprehensive PFM tool that is configured for the Indian market. For the folks in the US - I would direct them to Mint.com which provides similar capabilities and have personally been using this product since they launched.

In the subsequent blogs I shall try and provide some additional insights on developing globalized SaaS product and how adopting Services Oriented Architecture has helped us achieve this at a much faster pace than traditional development methodology. This approach is not just adopted by our product teams inside the company. Intuit does also provide 3rd party developers to access services at the Intuit Partner Platform and would recommend you check it out, especially if you want to develop and launch a SaaS based consumer or small business product(s) rapidly.

More to follow later and as usual feel free to drop me a line with your comments/feedback.

- Yogish

Issues with SOA Adoption

noreply@blogger.com (Unknown) — Tue, 7 Jul 2009 11:41:00 -0700

Here is my attempt to identify some of the reasons for failure to adopt SOA. This time the focus is on not having a holistic SOA enabling infrastructure.

Many large enterprises try to reduce vendor-lock by not having a single provider for their entire SOA development/ deployment stack. This philosophy works great from a risk management perspective. However, this risk management strategy directly competes with the “speed to market” gains promised by SOA.

1. Not having a unified platform that facilitates seamless integration across the service orchestration layer, the application layer, the data layer etc. leads to long system integration and debugging cycles
2. Not having a centralized facility for the end to end management and monitoring of services can cause long outages and hampers the ability to track information/ transactions flowing across the various layers of the service architecture (i.e. service orchestration layer, the application layer/ business logic layer, the data layer etc.)
3. Not having a holistic SOA governance suite that enable discovery of existing service assets at design time and that provides service utilization information at runtime causes service proliferation issues

The following blog by my colleague and co-blogger Yogish prompted me to address this issue as it speaks to Oracle/ BEA integration strategy two big names in the space of SOA infrastructure.

Analysis on Oracle’s BEA integration strategy

In lieu of the one year anniversary of Yogish’ blog I am being optimistic in assuming that this acquisition will lead to the creation of a holistic SOA platform that encompasses service interactions at design time and runtime. I am also hopeful that a single SOA platform will provide seamless integration across various layers of the architecture as in the service orchestration/ mediation layer, the business logic/ application logic layer and the data layer. In addition, my hope is that a stronger player such as Oracle (following the BEA acquisition) would start pushing for “SOA standards” and start holding other SOA players accountable for staying compliant with these (in much the same way that the other vendors would now be putitng more pressure on a stronger SOA contender such as Oracle (following the BEA acquisition) to abide by these same standards. This "peer pressure" will hopefully make interoperability an achievable goal.

In the event Oracle is able to pull together a holistic SOA stack then here are some advantages for its' customers -

1. Having one vendor support the end to end stack enables a customer to find the right support whether it be from the perspective of SOA product suite integration or from the perspective of availability of the right tooling to enable and enterprise to cut down its' service lifecycle timeline (service design, service deployment) and improve its' time to market.
2. Having a player such as Oracle that has traditionally focused on scalability, reliability and end to end monitorability will provide customers with a SOA platform that is robust enough to meet the stringent SLAs at runtime while making service availability more predictable and less of a guess work at runtime
3. Having one vendor provide a holistic service governance suite will allow an enterprise to reuse its enterprise service assets (if authored appropriately) thus enabling the business to compose existing services to offer new capabilities.

In conclusion, I want to state that I do not align with Oracle or any other SOA player but merely want to comment on issues that have hampered SOA adoption and how these might be addressed. I believe that a unified SOA infrastructure platform will be a key capability needed to truly realize the full potential of SOA.

Thanks for listening.
surekha -

Role of Events in taking Proactive Action

noreply@blogger.com (Unknown) — Sun, 17 May 2009 14:06:00 -0700

In exploring the role of events is it possible to achieve predictive analysis to provide rapid response and take proactive action?

One possibility is by tracking how humans handle event exceptions and locking their processing logic and turning this into business logic. This allows one to perform event correlations and to automate exception handling. Here event handling can take the form of rapid response or proactive action. Further, analysis of precursor events (i.e. events that occurred just prior to the exception) could lead to predictive alerts to be raised to circumvent exception situations and thus enable proactive actions to be taken.

If sensors and RF ID technology are the first steps to event capturing and event processing then addition of event analysis and event composition (Complex Event Processing style) is the next step in the evolution with exception based learning and proactive action based event emission may be considered a more advanced step in the process of EDA.

Many transportation companies and carriers and just in time supply chain providers could adopt EDA for rapid response or even proactive action. For example, combining weather based events, traffic flow patterns etc can be used to insure quality of the goods being transported to minimize wastage in transport. Furthermore, containers that transport organic food that does not use preservatives could use special types of "sensors" that detect the emission of gases and chemicals within the shipping container chambers to assess the freshness and the ripeness of the produce. If these events indicate rapid ripening proactive action based events can be sent to these shipping containers to lower temperature etc. to retain the freshness of the produce for transportation with minimum damage. (This example is only illustrative as I am not a expert on this subject.)

It must be noted that traffic and weather based events are combined with information about product preservation rules, correlated and processed to preserve sensitive consumer products to safely and preserve the high quality after this type of behavior has been observed in the human actor and this exception processing logic has been codified for future automation. EDA in this case is utilized for the purpose of tracking human exception processing and then automating this behavior albeit all the while depending on incoming current state events and outgoing proactive actionable events.

It seems very much a plausible use of EDA and so I am curious how many of you are using EDA for solving similar use cases.

As always your input is very valuable.
surekha -

Missing-link between Business Architecture and Service Oriented Architecture (SOA)!!!

noreply@blogger.com (Unknown) — Mon, 2 Mar 2009 10:28:00 -0800

Before we embark on the effort of establishing a link between Business Architecture and Service Oriented Architecture (SOA) here is an attempt at creating a loose working definition for each.

SOA is an architectural paradigm that allows one to model, build and measure reusable business components that can be flexibly assembled to offer a business service.

Business Architecture is an architecture style that structures the accountability over the most important business activities (for instance production, distribution, marketing, etc।) and/or the economic activities (for instance manufacturing, assembly, transport, wholesale, etc.) into domains.

To begin with here are a few key SOA principals that all apply to the realm of Business Architecture. Principals of loose coupling, abstraction, reuse and interoperability (of both messages and the operations) all of which facilitate composition of more course grained business services.

So what does a Business Architecture effort entail and how is SOA relevant to the discipline of Business Architecture? Business Architecture should focus on broad reusable business components that can be turned into or wrapped into reusable service components and/or business services. The term reuse has received a bad wrap but when looked at from the lens of being able to offer enterprise wide consistency and cross-business area interoperability one begins to realize that this very attribute of “reuse” has the potential to deliver speed to market and cost reduction both of which are touted to be powerful selling points for SOA. From this perspective Business Architecture can be seen as a precursor to SOA.

Business Architecture should be designed to help align the right business operating model (low cost services provider or innovation oriented service provider or niche services provider or a service provider that offers low cost processing to meet regulatory compliance needs etc.) with the value chains and the component business processes. Following this effort one would need to study how to alter business activities and those value chains that are directly impacted by the changing business needs (which are external influences to the operating environment). Without undertaking this study it is not possible to identify "appropriate" business strategies that fit the underlying operating model chosen by the business. This effort has to precede SOA based service definition work as this thought process enables rationalization of the current state “service worthy assets” and helps in the identification of business service interface for these assets.

Given the above description of the discipline of Business Architecture one would logically arrive at the conclusion that for the concept of Business Architecture to truly take root in any organization it is imperative that business strategy be considered the "driver" of the Business Architecture effort(s). In addition one will notice that package solutions and infrastructure / frameworks can only be treated as an enabler for the identification of business optimization opportunities (within the value chains and their component business processes) but are definitely not the drivers of Business Architecture work or SOA work. There are some other considerations as well such as the role of a Business Architect, the executive sponsorship for Business Architecture etc.

The role of a Business Architect is a critical aspect of Business Architecture to succeed. Since the “business aspect” of Business Architecture is important finding someone with the right type of business knowledge to fulfill the role of Business Architect would be a must have. Also, having someone with the ability to apply the philosophy of architectural abstractions to the business domain is important. Fortunately for us architects this is great news as some of the lessons learnt from SOA can now be easily translated to the realm of Business Architecture long as we have the right level of business expertise as well.

Having said that, Business Architects will need to be cognizant of the fact that they have to strike a fine balance between their technical and business skills. In addition, people in this role have to be careful to not engage in prematurely promoting the principal of business process abstraction (a core architectural principle), without first establishing the right foundation for introduction of this concept. The reason is that the Lines of Business owners possess a very keen sense of pride in being “unique” and abstractions often lead to the erosion of or removal of “unique” customizations where ever these interfere with the larger scale intent of the business process/ value chain.

Business Architects need to have enough business savvy to engage with their business partners on an equal footing. They have to first express the nuances of the various problem domains before they start the process of abstracting and drawing parallels across the business processes owned by the multiple Lines of Business. Even during this phase Business Architects have to be able to explain these abstractions in business syntax and show how the competitive advantage “uniqueness” can still be incorporated without loosing operational efficiency. To be able to articulate the concept in business lingo and to tie this to financial impact by walking through the underlying analysis is the only way to get business buy-in given that these are the metrics up on which Lines of Business owners are measured. If not done by garnering the right partnerships the resultant enterprise-wide operational efficiency or competitive advantage benefits would never be realized.

If one cannot find this Business Architect, a cross-functional team with complimentary skills may be able to pull this off. In order for such a cross-functional team to be able to execute effectively on any large scale Business Architectural/ SOA effort it must have the support of a prominent executive sponsor. The executive sponsor has to be able to articulate business strategies, and influence key representatives of the Lines of Business to collaborate with a group such as the Enterprise Architecture Group. Executive support of such a team enables it to effectively analyze and abstract broad Business Architectural constructs and can help define and drive business solutions to implement business strategies that align with the chosen operating model of the organization.

An oft asked question on executive sponsorship is whether it is the CIO or the CEO and the influence that technology has on such an effort. This depends on the type of organization, the charisma of the CIO and the business acumen of the CIO vs. the technical acumen of the CEO. Also, key to this decision is whether technology is a business driver for this organization or is at least a key component for driving the operating margins.

Finally, for Business Architecture, the related SOA work and the business solutions to be considered part of a sustainable model this body of work has to deliver tangible and measurable benefits. The measures and the value proposition will have to be agreed upon at the outset of embarking on this path/ journey. In addition this multi-step journey has to be associated with a set of well-understood and well-published multi-year target business deliverables.

For some additional information on Business Architecture please review content on related blogs:
Business Architecture – Process Architecture and Information Architecture!
Key Best Practices - What is Service Orientation?

Thanks in advance for your feedback.
Surekha -

Economy and IT

noreply@blogger.com (Unknown) — Thu, 19 Feb 2009 07:45:00 -0800

All the bad news about economic downturn got me thinking that there are a few parallels to be drawn between the cause and effect of current economic situation and IT. Just like American consumer, we have to start thinking about making some adjustments that will be required in future. Lets look at some of the parallels first:

Exotic instruments – One of the reasons financial system came crashing down was the invention of exotic financial instruments such as Collateralized Debt Obligation (CDO), Credit Default Swap (CDS) etc. These instruments were not well understood by majority of people that were peddling it or those that bought into it. We in IT world have been living in alphabet soup of our own – EAI, AI, SOA, BPM, CEP etc. While some of these acronyms have legitimate meaning, most are there to sell products or consulting services. In financial world these instruments have led to illusion of profit thus fat bonuses for undeserving people. In IT world this has also led to fat profits or career advancement for undeserving people

Sub-Prime Mortgages – IT equivalent of sub prime mortgages is the foolish investments we have made over time in technologies that have failed to pay back (they are the financial world's equivalent of "Upside Down" mortgages). Now, any new technology investment is risky and we should not be totally risk averse otherwise we will miss the opportunity to take advantage of transformative technologies such as the Internet, but at the same time we in IT tend to over hype any thing new. "If only I go ahead and buy a new CRM package, I will have better customer relationship." I am sure every organization has a number of expensive software products that have either been abandoned or are under utilized.

Next time I will talk about the adjustments. Anyone here with me for a “BAILOUT”?

Ashok Kumar

SOA is not.....

noreply@blogger.com (Yogish Pai) — Mon, 9 Feb 2009 06:55:00 -0800

Looks like there is a contant need to educate the industry on SOA and this time I shall take a stab at what SOA is not....

SOA is not about technology
Web Services is not SOA
SOA is not dead - it has the same symptoms as global warming (too much pollution in the air)
SOA is not defined as "A camel is a horse desinged by a committee"
It is not a case of Chicken (Business Architecture) and the egg (SOA)
SOA is not entirely about reuse
SOA is not expensive - it follows Archimede's Priciples :)
SOA is not a product or a platform
SOA is not about registry & repository
SOA does not start with a big bang

Just my thoughts and please do feel free to drop me line with your comments and/or feedback.

Yogish

Thoughts on Finding Value in BPM/Workflow Technology

noreply@blogger.com (Unknown) — Mon, 26 Jan 2009 12:56:00 -0800

I found an interesting entry on my colleague Todd Biske's blog Finding Value in BPM/Workflow Technology.

Here are some additional thoughts on how the value proposition for the BPM and Work Flow Management tools could be taken to the next level.
1) Ability to incorporate "Rules" or a "Rules Engine Component" into a business process step or a work flow task would be a great addition to these BPM/ Work Flow Engines. These rules can be encoded best practices or they can be regulatory in nature or business algorithms that may be volatile while the process flow or the work flow may not be so.

2) Ability to perform impact analysis for any process flow change prior to releasing the "new process".

3) Availability of analytical tools that could suggest optimization opportunities that could make process improvement suggestions such as the following
a) how switching the steps in the process may benefit the overall process flow
b) how metrics show that there is a ton of waiting in a step that could be made optional based on some criteria
c) how analytics could drive other optimizations such as making suggestions for automation of an information gathering step

4) Ability to subscribe to regulatory bodies that govern the outcome of a particular step of the process flow.

5) Ability to create a business process template for oft used processes within an industry vertical that allow standardization in the overall flow while catering for customizations and competitive advantage optimizations in particular steps of the flow.

Best Regards!!
- surekha,

Have you heard for Ahmedabad? If not - you should

noreply@blogger.com (Yogish Pai) — Sat, 24 Jan 2009 13:14:00 -0800

Ahmedabad is the largest city in the state of Gujarat (India) and is a few hundred miles north of Mumbai. This is also the city where Gandhi had his ashram where he start the non-violent movement for freedom from the British rule.

It is very unlikely that you have heard about this city, other than maybe seen it in the Gandhi movie not knowing the name of the City. Based on my recent trip there earlier this year I believe that it has the potential of becoming one of the major International cities in India .

Following is my reasoning:

The state of Gujarat was hit by a major earthquake in 2001 which resulted in thousands of death and substantial damage to the infrastructure. From this tragedy rose an opportunity (and which I sincerely hope we repeat the feet to overcome the current financial crisis)

The state and the city rebuilt all the major roads include some highways that are mostly 6 lanes wide (OK the extreme two are now used for parking). Even though there is traffic - it keeps moving and one can go from one end of the city to the other without any major traffic blocks (unlike the other major cities)

In the late 80's early 90's the pollution was horrible, especially at the center of the city where they had the highest level of pollution of any of the cities in India. Today they have provided incentives where majority of the auto rickshaws have switched to CNG (see picture below).

The city is the banks of river Sabarmati and they have now embarked on ambitious multi year project (SRFDCL) to develop the riverfront on both the banks of the river from one end of the city to the other.

Even though the traffic is OK now, in order to cater to the growth the city has embarked on one more project of developing a Rapid Transport System (BRTS). Instead of developing a city metro/rail system, they took a faster an more practical approach. The city has built dedicated special center lanes for express bus. In addition, they have also built a number of flyovers to facilitate rapid transportation. Something to learn from, it may be cheaper and faster to develop rapid transportation system using buses than developing a city wide metro/railways.

The city boasts one of the best Management Institutions (Indian Institute of Management - Ahmedabad) in the country. Ofcourse there is also the Gujarat University (a large campus) with a lot of well reputed colleges and research centers around it.

Looks like Indian Institute of Technology (IIT) is expanding into more cities, include Gandhinagar (IIT Gujarat) which could basically be considered as one of the suburbs of Ahmedabad

There are lot of other cool stuff about Ahmedabad and if it looks like I am biased - Yes! I am. In the spirit of full disclosure, I spent my first 19 years at Ahmedabad.

What does this have to do with SOA or Strategic IT? Very simple - the State and the City realized that the city was becoming unlivable because they were not providing adequate services to their citizens. In order to improve the quality of service - the combined their efforts to first plan and build out the infrastructure (still WIP) to try and provide one of the best living conditions in the Country. Something we can all learn from.

Key Learnings:Drawing parallels between Design Patterns and the principles of SOA - Part II

noreply@blogger.com (Unknown) — Wed, 14 Jan 2009 10:52:00 -0800

This blog entry attempts to expand on the concepts explored in a prior blog of mine Key Learnings: Drawing parallels between Design Patterns and the principles of SOA that deals the relevance of design patterns in the world of SOA and services. Patterns explored previously were the Facade, Abstract Factory, Builder, Factory and Bridge.

In this blog we look at how infrastructure components like the ESB that are part of the service mediation layer insulate the service consumer from the service provider by offering call-dispatch functions that map out the most efficient call execution path for honoring a consumer business request। Many of the constructs of the service mediation layer provide add-on capabilities which are in fact model driven implementations of common design patterns।

Adapter - modifies an incoming method call to fit the required method signature or definition of the provider without impacting the consumer

Transformer - adapts the parameter and return type or message format (which includes alteration or interpretation of the message content) and enables the insulation of the consumer information from that of the providers'

Decorator - augments the behavior or is a facility to add on to the behavior without altering the interface and breaking the service interface and service contract as new consumers need additions to the base business behavior

Interceptor - provides ancillary behavior, filters out information or calls to the provider, validates the message content for authN credentials, authZ/ entitlements and permissions etc। all of which provide important ancillary behavior to the provider without having the providers' service implementation layer having to be peppered with nonbusiness logic level code।

Finally, the point of this blog is to show that despite vast numbers of changes in technologies and technology based service offerings the basic design principles and design patterns of the object oriented design realm are still applicable। Knowing these and applying these carefully enables one to retain the durability of the service interface and protects the consumers from unexpected or non-deterministic results and exceptions.

Thank you for listening. Your input is invaluable!

- surekha

Architetcure in 2009

noreply@blogger.com (Unknown) — Sun, 4 Jan 2009 08:14:00 -0800

This will be my first entry into the blog for 2009. It has been a while due to a lot of churn over last few months. I am happy to see 2008 go. The only fear I have is that at the end of 2009, I don’t want to be longing for 2008. What a brutal year. I am hoping that people have learnt some lessons that you can not always focus on short term results at the expense of doing the right thing that has long term value. Architecture falls in that long term value category, yet first thing organizations do when it comes to cutting costs - they sacrifice architecture. Why do we keep rewarding people that cause untold harm in the long run while seemingly achieving short term goals? Most IT organizations fall into the same category. Senior executives are rewarded based on short term gains or operational efficiencies at the expense of long term viability. Current environment will only exasperate the situation.

It seems to me that executives and boards have not met the responsibilities entrusted upon them. Most executives have only been interested in benefiting themselves. I believe that executive bonuses should be kept in escrow and only be handed out at least 3-5 years after they are eligible to receive it. The disbursement of bonuses should be contingent on meeting some tough criteria where it is clear that no long term harm was brought upon by actions of these executives that may have fattened the bottom line in one year but killed the company over long haul.

My apologies for ranting but it has been very frustrating last few months. Now we need to focus on future and adjust accordingly. One trend I am seeing is that without clear, measurable ROI, funding is going to be scarce. There are fewer (if any) opportunities to experiment. This also means that vendors will have to adjust their expectations and will have to prove beyond power point slides that their product is worth investing in.

Happy new year everyone.

Ashok Kumar

Doing a lot more with a lot less in the current environment

noreply@blogger.com (Yogish Pai) — Mon, 29 Dec 2008 01:56:00 -0800

Given the current market conditions all business executives are once again challenging the technology teams to do a lot more with lot less. Following are some of my thoughts around this (nothing new - just going back to the basics).

Focus on solving your customers needs - independent of the industry.
Do not scale back on innovation. All markets typically are different when they come out of a recession that what they were before one. It is only those who focus on innovation shall come out as winners.
Focus on your core business - differ the adjacent market until the market recovers (unless it is related to the innovation)
Do not focus on developing new infrastructure (unless absolutely needed). Build out the infrastructure incrementally as new products and offerings are either upgraded and rolled out to customers.
Do invest heavily on large packaged applications. As the entire market is going through a shift - it may not be wise to invest in large packaged applications. It will consume a lot of resources (and $$$) without any major differentiation. It may be easier to subscribe for the same applications from a SaaS provider.
Do invest in a few strategic initiatives
Do not attempt to crawl before you run - "run baby run". The company that runs the fastest to meet the customers demand WILL WIN.

Just some of my final thoughts to close out 2008 and as usual please do feel free to drop me line with your comments and/or feedback.

Wishing everyone a very happy and prosperous new year.

Yogish

Key Learning from reclycling

noreply@blogger.com (Yogish Pai) — Wed, 3 Dec 2008 23:32:00 -0800

Over the long weekend I decided to recycle all the boxes that were in my garage and following were my observations:

I had not recycled the boxed for a very long time - so it was complete mess in the garage.
About a decade back you could just put the boxed out and the garbage collectors would take it for recycling - not any more. We now need to break down the boxes - flatten them and stack them in the provided container in a systematic manner - otherwise they WILL leave them behind.
As I was breaking down the boxed - realized that the technology has changed. It is very easy to flatten and stack them.
However, there were a couple of boxes where I need to use brute force, cut them and even stand on them to forcefully flatten them. Some of them were recentely manufactured ones - guess they did not use the latest technology
These days - eveything seems to come in box, no matter what you buy.
It is important to recycle the boxed on a weekly basis - instead of waiting for a long time. The longer you wait the worse it gets.

Hmm!! - haven't I heard this before? :)

Yogish

Architecture Organization Patterns

noreply@blogger.com (Yogish Pai) — Sat, 8 Nov 2008 13:44:00 -0800

Over the past couple of years I have observed that companies from the high-tech industry are adopting two distinct patterns for organizing their architecture team.

Centralized Organization:

This is true for most IT organizations led by a CTO-IT, VP EA or Chief Enterprise Architect
All EA members reports to the head of the EA team
Individual EA are either focused on some core technology, IT functions (such as networks and operations) and Business Domain
Business Domain Architects dotted line report the head of LOB-IT (typically the Divisional CIO)
LOB-IT may also have Architects who dotted line report to the member of the EA team

As IT organizations need to focus on what is best for the enterprise - rather than on individual business units, this is a preferred organization structure adopted by IT organizations.

Federated Organization:

Most of the High-Tech companies have adopted this model for their line business (with IT adopting the Centralized Organization)
Typically there is a Chief Architect for the company who reports to the CTO of the organization
Evey business unit has a Chief Architect who directly reports to the Head of Engineering of the business unit and dotted line to the Chief Architect or the company.
The Chief Architect sometime reports directly to the GM of the Business Unit.
The GM of the Business Unit and the CTO typically report to the CEO
The head of engineering reports to the GM or is also the head of the Business Unit (varies - no consistent pattern observed)
The success or failure of this pattern is directly dependent on the leadership skills of the Chief Architect of the Company
The Chief Architects of the Business Units also play an important role and will be effective only if they constantly communicate to each other

As the GM like to have a sense of ownership - this organization pattern makes sense of the High-Tech industry. If the Architecture team is centralized under one Chief Architect - my observation has been that the GM then hire their own Chief Architect (under some other title) which creates a huge organization conflicts.

Some Interesting Observation:

One of the companies during the transformational phases transferred all their key resources - including development managers, developers, DBAs, Operations, etc. to the architecture team. Made a public statement that Architecture team was core - reorganized the rest of the teams and later over the three year period transferred the folks back out to the new organization. Using the Architecture team to retain the best resources during their transformation phase.
There is a 50% split between Shared resources team as being part of the Architecture team or an independent team.
Lately over the last 12 months - a lot more companies in the Silicon Valley are looking or Chief Architects responsible for both Business and Technology Architecture. However, they do not explicitly mention Business Architecture in their job description but their job description includes Business Architecture responsibilities.

Just some of my observation about the Architecture Organization Patterns and as usual please do feel free to drop me line with your comments and/or feedback.

Yogish

Comparing Current Financial Crisis to SOA - Continued

noreply@blogger.com (Unknown) — Sat, 25 Oct 2008 09:58:00 -0700

I agree completely with Yogish's views as posted on "Comparing Current Financial Crisis to SOA" and his advice on treading light and having solid justification prior to undertaking SOA style projects.

A) An upfront investment has to be made in performing the right level of business process analysis and business architecture to pick the right SOA service candidates.

B) One should not attempt embarking on SOA with a highly visible project, as these types of projects operate under unwarranted pressure for delivery and with little patience for "architectural constructs" SOA or otherwise!!

C) Any project that is a high return type process with established KPIs and benchmarks is a good candidate for first time SOA implementations. Here gains are measurable (in the form of cost avoidance, cost reduction etc.) and can be directly tied to SOA-enabling these operational processes.

D) One has to invest in marketing the success of these projects and the services that were responsible for these quantifiable returns delivered by following SOA principles. Advertising the benefits of SOA style services with the benefits rendered by these projects help the business to relate to the abstract constructs such as SOA and so offer a better chance for service adoption. Also, advertising these business services that deliver efficiencies can be shown to offer speed to market gains that can be used for upcoming projects by encouraging reuse.

E) As always one should not assume technology will be the magic bullet. An assessment has to be made to understand if all components of the process/ business capability have to be refactored into services. One has to be open to leveraging legacy assets to reduce risk even if all that can be achieved is establishing a document based interaction or a mediated invocation of the legacy system.

Your feedback is invaluable.
Thank you!!
Surekha -

Comparing current financial crisis to SOA

noreply@blogger.com (Yogish Pai) — Sat, 18 Oct 2008 12:46:00 -0700

Comparing the current financial crisis with SOA was one of the topics we briefly discussed at the Community of Practice working group of the SOA Consortium. Following are some of my thoughts on this topic:

The current financial crisis is based on a flawed foundation - the sub-prime mortgages
Investment bankers and mortgage companies composed new and complex derivatives and resold them all across the globe - all in the name of new and investment models
Most of the executives of the involved companies as well as government agencies reviewed some of the aspect of the new world and based on what they knew then - thought it was all OK.
No one seriously took time to review the potential business risk and take corrective action before it was too late
The investments were so interdependent which made it impossible to understand the implications or the impact of letting one service fail. Example: The is no rational on why Lehman Brother was allowed to fail? and why AIG was rescued?

...and we see the result today. Doesn't this sound familiar?

Following are my recommendation on how to make sure that our SOA adoption does not take the same path (some will).

Make sure that all SOA adoption is based on sound business and technical foundation. Adopt and make sure to document the business architecture (design) and develop a technology road map (architecture) to meet these goals.
Do not hype and push rapid adoption without thinking through the life cycle .
Ensure that there is proper governance around your SOA Adoption - over communicate and be a bit more conservative on the risks.
It is not necessary to adopt SOA for all implementations - I would rather then to recommend that one makes sure that some of critical business capabilities (applications) are provided (build) using the traditional model.
Do not depend on services that are more than two level deeper (Reference: SOA Theorem #4: Service Hierarchy should not exceed more than three levels ). This is to ensure that you understand each of the services and their performance which will help you take corrective action, if required.

These are just some of my initial thoughts and as usual please do feel free to drop me line with your comments and/or feedback.

- Yogish

Canonical Models and Services

noreply@blogger.com (Unknown) — Mon, 13 Oct 2008 07:45:00 -0700

In thinking about canonical models one mostly thinks about an enterprise worthy or industry compliant representation of a business concept or a business entity। Often this canonical model compliant payload is packaged in a response envelope that is returned by the service provider. However, the question is whether the term canonical model can be used to define the " business request" or if it is limited to the "business response". This blog explores the canonical request models that might be used to alter the behavior of enterprise services using search services as an example.

Let us look at a "search service" where one could think of a "context based search request" that is made to the search facility to make the search behavior of the service providers more efficient। In addition, this "search context" could also be used to express the specific search needs of the service consumer. Given this, the question is whether the canonical model could be used to define a request model that is a representation of the service provider search/ browsing parameters and service consumer's usage context. Here the search capabilities of a search service could use search/ browse related grammer rules to interpret the search context that is embedded into the request by the consumer. The context provided by the consumer allows the service provider to "accurately" and "efficiently" interpret the request.

For example, search semantics embedded in a search service that returns cross-sell product options could include information like "customer preferences", "type of credit card used by customer", "shipment processing preferences", "customer purchase history" etc। This type of "customer information" represents usage semantics embedded in the request and allows the provider to return cross-sell product options that are geared to the the specific customer being refered to by the consumer call। This in turn allows compilation of product suggestions which incorporate the profitability levels and purchase ability of this particular customer. The "customer information" is deemed to be the search result and usage context that are sent into the search request. These search results are thus customized to the consumer context without the consumer needing to make multiple calls to get the desired results. Therefore, one could see how the canonical request model has not only the standard search parameters supported by the provider but also allows the consumer to express its' search context and how it might apply the results of the search/browse call.

In addition, the canonical request model based search context could be used by the consumer to drive processing efficiencies in the provider। These request based keywords/ context can help the provider eliminate or short-circuit certain types of processing as well. For example, a canonical request model could support "new customer search" vs "existing customer inquiry" keywords to help alter the providers' audit processing behavior and past inquiry Here a consumer call with "new customer search" context could be used to suggest to the provider that the audit/ security and past inquiry lookup be disabled thus positively impacting the response time of search call.

In conclusion, we can see that the consumer usage semantics allow the provider to tailor it's search behavior to the needs of the consumer without changing the provider service interface.

Please give me your feedback on this topic। Also, I would be interested in knowing whether or not you have leveraged these concepts in your industry vertical।

Surekha -
Thank you!!

Organization Skills assessment and Reference Architecture

noreply@blogger.com (Yogish Pai) — Mon, 6 Oct 2008 20:18:00 -0700

The other day I was participating in the engineering skills assessment discussion and it dawned on me that mapping the skills to a reference architecture makes is much easier and simpler discussion to have. The reference architecture enabled us to first list the categories and drill into each of them to define the skills as well as leveling required for Architects, Developers, QA and Managers positions.

Key Learning's:

Having a reference architecture also helps in organization (engineering) skills assessment
The Skills Assessment / Mapping is independent of Governance and Organization. However, Governance drive where these resources belong

SOA Consortium announces SOA Case Study Winners

noreply@blogger.com (Yogish Pai) — Fri, 26 Sep 2008 17:33:00 -0700

The SOA Consortium and the CIO Magazine this week announced the winners of the SOA Case Study competition. Please click here for the results.