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

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

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

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

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

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

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

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

1. SOA is not about technology
2. Web Services is not SOA
3. SOA is not dead - it has the same symptoms as global warming (too much pollution in the air)
4. SOA is not defined as "A camel is a horse desinged by a committee"
5. It is not a case of Chicken (Business Architecture) and the egg (SOA)
6. SOA is not entirely about reuse
7. SOA is not expensive - it follows Archimede's Priciples :)
8. SOA is not a product or a platform
9. SOA is not about registry & repository
10. 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