EA - Enterprise Architecture in Action

In some of my interactions with clients, discussions around SOA are met with diverse outcomes. They vary from

1. We have decided to have an enterprise-wide SOA. Can you help us build a strategy?
2. Help us get started by putting foundational components and work on a portfolio
3. We are not ready for SOA yet
4. Why do we need an ESB, UDDI, repository, registry? Suite vendors are asking us to buy stacks!
   

While 1, 2 and 3 are acceptable outcomes, the aggressive move by suite vendors to sell all encompassing solutions has bewildered and completely confused users who were almost ready to buy their products in an incremental way.  The absolute necessity of an ESB in an SOA is almost as necessary as a canon on commercial airlines. It is the cart before the horse syndrome. In one of Jason Bloomberg’s articles on Who’s killing SOA, he points out that the platform vendors have a major role to play.

I can easily identify myself with clients who need to show real business outcomes in 2 – 3 quarters, if not less, whereas in the buy my whole suite scenario, the environment setup alone could take a few quarters and a full service SOA can take a couple of years (btw standards are still happening).

The progression from asset discovery to service modeling, which is the core of an SOA implementation is hardly mentioned. Neither is the need for change management with respect to organizational roles alignment and funding models which are foundational problems for SOA.

Many organizations which have been reasonably successful in their SOA path already are those that have mentored their teams into building applications from loosely coupled services.

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

In my previous post, I was musing about the increasing significance of Enterprise Architects. Continuing from where I left off, it is interesting to see others also striving to define the Enterprise Architect. There are a lot of different definitions for “enterprise architect.” It can get really confusing, particularly if you follow a lot of blogs written by enterprise architects — and I did.

I came across a few interesting blogs on technology managers and EA. Ed Gibbs blogs on Moving to Enterprise Architecture, the blogs on successful software architecture and Six Sure Fire ways to Sink your Enterprise Architecture also made for an interesting read.

Fact is that work being offshored to/by software services companies is highly technical in nature. Bulk of such technical work involves translating requirements to workable solutions and also to ensure that such solutions continue working according to Service Level Agreements (SLAs) defined by businesses. It is therefore imperative that initiatives get the required oversight from technical experts and stakeholders. Such oversight includes review of architecture and design for use of industry best practices and conformance with the required Quality of Service QoS. The real skill comes in contextualizing the applicability of technology, validating best practices and reuse in the specific business and enterprise context.

In an offshored context, there is no reason one cannot leverage offshore architects for required architectural inputs, review and governance. Thanks to pervasiveness of information about ‘technology building blocks,’ base frameworks and body of knowledge, best practices can be leveraged from across geographies where technical experts may happen to reside.

Bottomline: one can extend the theme from "A Litmus Test for IT" Just as the blog says "a good IT department should be able to describe the business problem – that the company’s definition of a customer is changing – and explain that the project it’s working on will update the systems to reflect that. If the IT guys start talking about a new data warehouse that can rationalize customer records it might be time to worry" An Enterprise architect too should be able to describe the business problem.

- Mohan Babu K.

Posted by Guest Author at 3:39 AM | Permalink | Comments (0) | TrackBacks (0)

I read the recent BusinessWeek article “The Comeback of Consulting” with more than cursory interest. Having donned the consultant hat for my employer’s strong technology strategy consulting practice, working with clients across verticals, I can empathize with the resurgence in the consulting services that the author is talking about (though the article does not specifically focus on technology consulting). This viewpoint, when read along with the recent CIO magazine write-up "Hot Jobs Enterprise Architect" gives an interesting perspective. [Tipoff Agile Elephant] The article talks about how "Consultancies and systems integrators are good places to look (for Enterprise Architects), since staff there have honed their IT and business skills on a variety of IT projects focused on different industries and technologies."

To this, I will add Offshoring and sourcing perspective as a must-have skill that Architects working for services firms acquire. You may be wondering why firms should engage with an offshoring service provider, especially for Architecture consulting services. If you are expecting the ‘obvious’ answer [‘low cost’?] you might want to think again. Architecture consulting is an area where the maxim of ‘working with an offshore service provider is cheap’ gets flipped upside down. Such consulting services are certainly not cheap, especially when provided onsite and when stacked up against conventional ‘offshore billing rate.’ But the real driver for clients to engage with us and other offshore providers is the value, especially when such consulting is bundled with offshoring.

And what is in it for individuals who wish to pursue a career in technology consulting? The answer to this was provided by the CIO article that concludes "Sony was able to get two out of four application architects to jump to the next level and become enterprise architects. The pair who didn't make it only had software development experience, while the two who succeeded had those skills as well as backgrounds as IT consultants."

Note. In case you are wondering what exactly is involved in ‘technology strategy’ consulting: The gurus at Infosys have tried to describe it as “Architecture Services enable you to eliminate the Business-IT alignment dysfunction. We partner with you to address your concerns and develop implementable Enterprise Architecture (EA) solutions to translate your corporate strategy into an effective IT strategy. These services provide you a fact-based evaluation and selection process that best fit your IT roadmap.”

- Mohan Babu K.

Posted by Guest Author at 4:34 AM | Permalink | Comments (0) | TrackBacks (0)

What is that SCA does which WSDL couldn’t already do! ?

Well, on the face of it, it may look quite an answerable question but its implications go deeper on second thoughts and perhaps makes one think deeper about the future of SCA and perhaps make educated guesses about it. Here, I will try to answer this question and one need not know anything about SCA (except that it is a superseding component specification model which promises the heaven – no plumbing code only business logic, remember!).  I will assume you have fair understanding of WSDL. SCA promises to be an interesting component specification on the horizon and backed by big names such as IBM, SAP, etc. so no harm spending some time understanding it. Seems like it is logical evolution from the J2EE component specification and some basic ADL concepts – component, interface and connectors…In fact most of the concepts are familiar in the Java world (references, annotations, etc.).

Let me start with WSDL which I will assume we know – it is an interface description language. It provides us a way to specify the interface of a service – messages, message exchange pattern and the protocol bindings to be used to access the service and concrete endpoints (IP address, port number, etc. in the HTTP world) for accessing the service. So what does WSDL achieve? It decouples portions of the service interface from one other – say, operations, messages, etc. from the protocol bindings. This provides flexibility. Hence you could imagine a service interface A being built out of message parts B, operation C, and binding D as well as the same interface A being built out of message parts B, operation C and binding E. In fact, we could using the import mechanism of XML create multiple such service interface descriptions by combining parts of the WSDL. So WSDL provides flexibility at interface level. We are completely silent about implementation here…

If we bring in the implementation, then we have many more challenges. Imagine a crazy situation for example sake to understand the problem (of course in SCA it does not remain so crazy a situation after all). Let me have a C++ implementation to which I provide a CORBA IDL interface and I want to configure the C++ implementation with different database connectivity protocols (at will) and make this configured implementation (a component in SCA) available to a Java implementation which wishes to refer to it using a Web services protocol or better even having a COBOL implementation wishing to refer to this C++ implementation. Now, my requirements are I have these implementations which I don’t want to touch, and I wish to configure and wire them together in a descriptive manner (configuration files). Hence, the contraption on which these components would play would need to introspect these implementations (C++, COBOL, Java ) find if the implementation expose the promised and published interfaces (CORBA IDL, WS) and if these implementations can actually be properly configured (database connectivity) and if the source and target components interfaces are compatible and finally if the protocol bindings the interfaces demand can be made available between these components. An SCA based runtime can do all that. Which means an SCA runtime should support IDL, RMI, WS, COBOL, Java, EJB, BPEL, C++, HTTPS, HTTP, TCP, etc. etc. etc. Too much of a promise!!!???

Well, yes and no.

SCA has a wonderful extension mechanism by which you could extend the platform with new interface types, implementation types and binding types. So you have it. The specifications get into details of some of these programming languages, bindings and interfaces at the moment and specify how these have to be handled given the above set of requirements. So expect a chain of SCA related specs or appendix specs!

In the final analysis, SCA enables description of component to component inter-dependency. It specifies the component architecture, which WSDL is not concerned with. Secondly, SCA promises to provide tremendous flexibility in being able to specify, configure and wire components together – implementation to implementation flexibility (varying with properties), implementation to interface flexibility, interface to binding flexibility. So flexibility delivered in more areas than WSDL. And all this flexibility is provided through component and composite configuration files. Hence, the programmer can be relieved of writing a great deal of plumbing code (no RMI, no WS, no HTTP in his/her code) – only business logic! Sounds too good to be true? This is not entirely true however.

Suppose I am writing an implementation which is a POJO or an EJB. I still have to have put Java and EJB annotations for references, properties and services. The SCA specifications would also support Java and EJB annotations and then if I specify a Web services interface to it, the SCA runtime would introspect the code and verify if the published interface is compatible with the actual implementation using the annotations. I could now specify Web services or RMI binding for inter-component communication. However, I don’t need to write any Web services or RMI related code here. Only a few annotations in the code and a few configuration set up in the SCA composite files would suffice.

The concept of ComponentType is extremely powerful in SCA. In case the SCA cannot verify the implementation through introspection, it can use an accompanying componentType (which has been provided by the implementation supplier graciously) to discern for the “intentions” of the component – services, interfaces, dependencies, properties.

Some of these concepts are mature in the field of Java/J2EE and Web services and hence developers from this community may not find it shocking or eye opening at the first instance.

The promise and the future of SCA would depend upon how rich the vendor’s SCA runtime is, what performance and interoperability issue might crop up during implementation.

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