There is no straight answer to this question. One could argue for both sides of the camps and still make conclusion on either way. Let’s see why SOA is considered to be expensive by the people who are not so close to IT. There are several factors why SOA is perceived to be expensive (I would say only ‘to begin with’). But, remember SOA is expensive at the ‘beginning’ as there are few upfront investments required on Software Licenses, Infrastructures, Training etc. The lists below are the key areas of investments:
SOA reduces cost in all the projects within the enterprise throughout all the phases of the SOA SDLC when reuse (of Service) starts happening – Requirements, High Level Design, Low Level Design, Development/Build, Integration, Unit Testing, System Testing etc. The cost savings are in the range of 30% – 80% in individual phases.
However, there are few areas where the cost would increase everytime the reuse happens – Documentation, Training, Configuration Management, Programme Management etc. Although, the amount of increase in cost is negligible as compared to the saving achieved due to reuse.
After an organisation adopted SOA, reuse of Services increase year on year – e.g. 10-15% first year, 20-25% second year, 30-40% third year and so on – which would have direct impact on cost savings. More and more Service reuse means IT is slowing becoming an ‘assembly’ shop from a traditional ‘development’ shop.
On the flip side, one may argue SOA is not expensive even at the beginning. One of the most expensive piece of software is ESB may be considered as not part of SOA investment. Any organisation would need an integration layer irrespective of whether there is SOA or not. So why should I consider ESB as part of SOA investment?
Similarly, one must not consider Application Server or equivalent technology as SOA investment. Application Server is commodity these days and foundation of all applications/Services running within the enterprise. What about BPM? SOA does not mandate BPM – BPM can be there with or without SOA. What is left? What about Service Governance and Service Management Tool – these two could be the only pieces of software which are needed for SOA (although SOA does not mandate these, one can still achieve SOA without the tool).
The bottom line is - it’s the Architecture team responsibility to manage the perception of SOA within the organisation. All the investments required for an IT Programme is NOT because of SOA. Lets not relate everything happening in IT with the name SOA – then SOA becomes the obvious scapegoat when things does not go the way it should have been or when the cost significantly overshoots. IT has to keep in mind that Business has never been so close to IT. Business has far more visibility of what’s going on in IT as compared to 10-15 years back. I am not suggesting IT to hide on what’s going within IT from rest of the organisation but be cautious in terms of setting the expectations of non IT stakeholders. SOA is just another way of doing architecture which would enable IT to be more agile, flexible and business aligned.
SOA is NOT all about the technology. SOA is about making IT more mature while bringing all the ingredients (People, Process, and Architecture) together and making those work in a more predictable (Governance) way which has been missing in IT for years.
]]>
I recently visited CloudExpo London 2009 and had the opportunity to meet up with industry thought leaders, CxOs, architects, marketing gurus from the major players like Google, Amazon, Linux, IBM, Salesforce so on and so forth. This article is a synopsis of point of views (PoVs) from a number of sessions I attended during my visit.
So, why Cloud Computing (CC)? There was a general consensus among the people on the typical benefits of Cloud Computing.
During the session I asked a speaker from Amazon, so how do you implement your Amazon EC2 (Elastic Computing Cloud)? His straight forward answer in front of everybody was –"It is a bad answer – but we don’t disclose our implementation details." I could not help noticing the expression of annoyance on everybody’s face in that session. You have to take the word of his mouth that they are in the business for ages and maintain the records of more than 600 million credit cards (may be one of them is yours) - implies they are good at Cloud Computing which means they are good at security, scalability, stability, failover so on and so forth. I doubt if they are good at everything, may be some of you are convinced because they are Amazon.
My point here not about their capability, it’s about the Trust and Transparency and I think that is the biggest hurdle for Cloud Computing at this moment. So here is my problem as a technology service provider how do I guide my client where to go for Cloud Computing needs, if the underlying implementation details are abstract to me.
Gartner research indicates Security and Control are the most prominent issues and to resolve this we need to establish trust and openness. Having said that, I actually found some of the Cloud vendors have realised that point. After a session I had a conversation with a speaker from Salesforce, one of the biggest SAAS providers, and he entirely acknowledged the fundamental issue thwarting the progress of Cloud is trust. The action from their side is that they are taking security team from organisations like Citi, JP Morgan onboard for a visit at there Cloud hosting centre. I think Citi and JP Morgan are at least convinced a bit because they have hosted some of their non critical services in salseforce cloud.
Big players are more worried about security where as small players are sceptical about the whole concept of virtual shared environment which is the foundation of Cloud Computing. During one of the session while the speaker was discussing about Disaster Recovery, one of the CxOs was asking,’…if the infrastructure is shared with a big company, during a DR as a small company where do I stand? Will I be given same amount of attention?’ The argument here is that SLAs are there but at the time of DR billion pounds client may get priority over a million pounds client. Again it is a trust issue and the client is asking an SLA for SLAs :-)
One of the topic was being discussed widely was –‘The risk of vendor lock in’ Once you host your Services with a particular ‘Cloud’ provider and if you are not careful enough, there is always a chance of lock in. The danger is imminent and some of the organisations learnt lessons when locked-in with only one outsourcing service provider. How about hosting in multiple clouds with different vendors? It is possible only when the implementations are interoperable. If you look inside, some of the Cloud providers are having proprietary implementations behind those wonderfully smooth sailing Clouds. Definitely Linux is coming into the picture here together with IBM and they are making a point – when we are talking about multiple Cloud and inter-cloud communication, interoperability will be the most crucial point to address. I am sure there is a great opportunity for Linux and other open standard based communities to thrive.
I have no doubt we have done great progress in virtualisation in both software and hardware. But I still had to ask this question to one of the speakers "is our network infrastructure is ready yet?" One gentleman was shouting, ‘the bandwidth is not enough at Cornwell’, even it is not enough where I live in a place which is very close to London. Can the existing network provider handle the load of Public Cloud? Unfortunately no TELCO was there to take us through about its vision to support Cloud Computing. May be the developed countries are ready but what about the developing countries? There was discussion but no definite answer to my questions. I feel at this point of time Public Cloud may not be achievable from an end user perspective.
The feeling I got from the CloudExpo is that Cloud Computing is happening, the technology is available to support and everybody is looking forward to get some help and as technology service provider we have a big role to play. If we say Cloud Computing is the future then we got to take the responsibility to answer the following for early adopter (clients) and make the adoption far smoother.
IDC expects Cloud adoption will be amplified by the current financial crisis. Small and medium size organisations that were either scared of SOA or did not like the complexity -‘SOA Reference Architectures with ‘n’ different layers from different vendors’, now can have the full flavour of SOA without having to do it by themselves. This Cloud is nothing but highly virtualised Services in the SOA world.
Global financial crisis is changing business priorities and the IT that supports them, forcing IT to drastically reduce TCO and Opex. I think in this recession ‘Cloud Computing’ – this buzz word is going to draw a lot of attention and enterprise having right skill set & expertise would be able to position and getting into Cloud Computing should make would make good in road to the future business opportunities.
Development of composite application from scratch would involve design of the custom business processes unlike the case of xApps where the process definition is provided out of box. It would also involve exposure of the legacy application functionality and data stores as service components which could become first class citizen in the composite application. For example, in SAP CAF http://www.sap.com/platform/netweaver/cafindex.epx the underlying business services are converted into Callable Objects by wrapping them with SAP CAF-GP libraries. Hence, components from diverse types of back end applications (Knowledge management, Business Intelligence, LOB application, etc.) and implemented using diverse technologies (EJB, .Net, Web services, etc.) can all be brought to the same page – Callable Object. Once we have the configurable Callable Object the SAP CAF –GP platform can use these to assemble a new business process.
The role of Service Orientation http://searchsoa.techtarget.com/news/interview/0,289202,sid26_gci1189356,00.html in the composite applications is very important. The participating components in the assembled composite applications are service components (SCA/SDO are standards in this space) and not necessarily web services. A service component can use any technology for implementation (and not necessarily HTTP, SOAP, etc. as connoted by Web services) the only important thing is the usage of service orientation principle http://www.soaprinciples.com/p3.asp.
We are also observing the emerging of composite application platforms on the Cloud http://cloudcomputing.sys-con.com/node/746658, http://www.cordys.com/cordyscms_com/composite_application_framework.php, http://www.informationweek.com/news/software/development/showArticle.jhtml?articleID=217701723&subSection=News
In my next, we will look at some of the other composite application platforms.
]]>In most of the cases that I have dealt with, I have been able to successfully add value to client's thinking process and quality of their decision making as far as SOA is concerned. So that's reason I believe this input will help larger SOA consulting community as well as organizations that are for ever in hurry to jump onto SOA, what ever that supposed to be.
]]>In the IT industry, from time to time, we hear terms and notions that carry special meaning within the industry. Evergreen is one of them. One of the dictionary definitions of 'evergreen' is something that remains perennially fresh, interesting, or well liked. But what does evergreen solution or technology means within IT context?
Simply put evergreen can be translated to ever relevant. In other words, a solution that has the capabilities to sustain and adapt to changes, and to continue to re-innovate and evolve through service capabilities over time.
Is there any technology, architecture or process that can provide us with such a solution that remains ever relevant during its operation and life span within an organization?
In my opinion, no technology, architecture or process can provide such an evergreen solution that can meet today’s ever changing requirements and business needs; unless you engineer it to do so and consider all the enablers i.e. technology, architecture and process that help to achieve this goal.
Providing an evergreen solution is a subject that has many facets and IT practitioners have expressed their views on it and suggested many approaches for it. Some of these view points are as follows:
Each of the above approaches has its own interpretation of the evergreen requirement for a solution. Although there are different approaches, there is still some commonality between them as the end result is the same for all these approaches - i.e. building a solution that can sustain changes and innovate over time.
]]>Based on the findings of the pre-assessment, a decision to move ahead with the next phase (full blown Assessment) would be taken. In case of missing business case and lack of buy-in from the key stakeholders – the focus would be to create a business case and at the same time institutionalise the benefit of SOA within the enterprise. Without getting these two in place, there is no real benefit of trying to understand the current SOA capabilities through a thorough assessment.
At the end of the Assessment phase, along with the key findings and recommendations, SOA Maturity of the organisation is defined using Infosys’ SOA Maturity Model (please refer to the presentation).
With targeted recommendations for improving your maturity level, the Infosys SOA assessment framework/tool can help you unlock the full value of SOA.
For whole set of SOA offerings from Infosys, you can visit http://www.infosys.com/soa
]]>
]]> In any SOA integration project, inability to differentiate between these two entirely different categories of requirements leads to confusion and a sub optimal design. Key points to understand here is that logging is a key capability in detecting and resolving problems in any IT infrastructure and each SOA product supports extensive and configurable logging features in their own way. In SOA, the challenge lies in creating a centralized logging solution that can save the effort of mining plethora of logs created in variety of formats by different systems. There are various approaches to deal with this problem. These are few here:
I stumbled upon this article while reading some articles. As I read it, I heard a 'click' sound in my brain :-). My previous post of SOA's future, I speculated about fading of SOA's strongly hypothetical personality and come of age of BPM driven IT solutions.
]]> As far as SOA is concerns, Joe makes precisely the same point of having more real forms of technical reforms like web-architecture, cloud computing etc. successful today while SOA as a whole still struggling to get into action for most of the businesses. As Joe says 'SOA is too hard to understand and does not lend itself to people just doing it'. I completely believe in it. I have heard lot of experts and practioners on SOA in last 4-5 years. By and large my opinion is that 70% of those drag the topic ultilately to web-services or similar technical topics. Rest of the 30% who tend to remain pure in terms of SOA as a concept also fail to bring realistic and implementation-level view-point on how IT can be transformed using SOA. So in nut-shell, SOA is loosing the differentiation it tried to create all these years but good thing is that because of this hype, some good technical innovation will happen that hopefully prove to be next-generation foundation when BPM takes over from SOA..We are alreadying seeing vendoring lowering their SOA pitch and slowly getting to BPM pitch in big manner...:-) ]]>
1. Think Big but Start Small: Most of the organisation I have interacted with seems to be in real rush of realising the benefit of SOA as early as in just 2-3 months and that sets the expectation too high. This essentially in turn moves the attention from building the base SOA infrastructure towards implementation. As a result, lose track in the mid-way and eventually blames SOA for NOT being able to full fill the expectation. Instead, select a well thought of ‘Pilot’ (i.e. set of use cases) which captures end-2-end flow of the business and would have visible impact (Ah Ha! effect) and tangible RoI. Implement the pilot on a well established base infrastructure. Use the experience of the ‘Pilot’ to enhance your SOA processes (Governance, Service Life-cycle, Technologies, etc.). In the recent Gartner SOA conference in London, the same sentiment has been echoed by different organisations who shared their SOA success story.
2. Governance key to success: SOA without Governance is the perfect recipe for failure. SOA without governance is like ‘class full of brilliant students without a teacher’. SOA is lot more than just creating bunch of services. There is the whole notion of infrastructure & processes on which those services will be running & managed and external system with which those will be interacting with. To manage the complexity, there has to be a governance process based on well defined standards, policies and processes along with reviews, checkpoints, and metrics.
Don't take any short cuts when it comes to governance. You may eventually get there but it will be much harder to implement things at a later date. One can get there today, but several months from now on when there would be over a hundred services and a dozen projects in production, you better have this resolved now or you will be sweating hard then (and forget about the benefit of SOA) instead of working smart.
3. Govern policies that matter most: Policies are must to have to make the Governance easier and making SOA deliver the intended result. However, having too many policies and treating them all with same priority means ensuring things would not be delivered early (some cases never). So, it is imperative to focus on policies which are critical to making the business, IT and other involved parties work together for success. Focus should be to meet the customers’ expectations/needs and ensure that they are getting the same. Having too many policies is like ‘making every word bold in your email to highlight the message’ – defeat the core objectives. Having too many policies is just as ineffective as having none (maybe worse).
4. SOA is expensive: Bear in mind that SOA is not cheap. Building & managing reusable common services is expensive. As per the industry experts, making services re-usable is 2.5 times more expensive than building a software component. Then why SOA getting so much of attention? The fact is getting SOA working with first set of well designed services is expensive, but once you are running with SOA changing your business (fulfilling your business demand) is much faster and you start realising the benefit.
5. Make governance easy and do it early: Have governance in place early in the SOA adoption and follow the ‘KISS’ policy. More and more organisation have started realising the importance of having governance right at the beginning while SOA makes its journey through Gartner ‘hype’ to ‘disillusionment’ to ‘slope of enlightenment’ phases. Getting Governance right at the beginning (integral part of SDLC) reduces confusion and rework while governance becomes an integral part of the SOA journey without being a burden to the whole SOA team.
6. Get your Communication tool in place – Develop common terminology: Not a new ‘mantra’. Like any other abstract architectural approach, when talking about or arguing over something as abstract as SOA, just talking over phone or meeting in the coffee area is not going to do the job. Get it documented – use tools wherever possible. SOA team should use tools (Visio, Modelling tools) to capture the ideas – like service life-cycle, service orchestration etc – to get agreement faster.
7. Getting the right Interfaces are key: Don’t worry too much about your implementation of services. Well defined interfaces (with right strategy for versioning etc.) would make or break your services. One can implement the actual services in whatever way (technology, infrastructure etc.) they want which really does not matter as those are completely hidden (encapsulated) behind the interfaces. It’s unlikely that SOA would be ‘greenfield’. Most of the cases, SOA is a migration. So, keeping the focus on Interface is much more important than anything else.
8. Each service should have owner: Decide the ownership of the services upfront – again one of the aspects of Governance. For every service, ownership has to be defined at two levels - Business and IT. Business owners are responsible for the business capabilities of the services, including the cost of running it, and its value (business) proposition. IT owners are responsible for development, maintaining different versions of services, ensuring the service level agreements (SLAs), and making sure consumers of the service are satisfied with it.
9. Be pragmatic: No need to be perfect. Achieving perfection in SOA would make SOA journey towards failure as business would not wait for eternity for IT to deliver perfect SOA. Deviations are inevitable from SOA best practices and your organisation is no exception. So, need to have a plan on how deviations will be dealt with and accordingly tracked as part of the governance process.
10. SOA is to change Business: Treat SOA as a business opportunity not a re-platform program. So start with business process design – a top down view – which would provide right insight into what business services to be designed. This would help to get business view of SOA right at the beginning and be easier to manage business stakeholders
11. Managing Stakeholders key to success: Setting the expectation to key stakeholders (Business & IT) and keeping up to that is must for successful SOA. Every stakeholder would have different expectation (in terms of benefit) or see SOA differently – like ‘the Six Blinds and Elephant Story’. However, we need to ensure that everybody understands the value proposition SOA is bringing on the table and aligned with that. This would help addressing the funding challenge and buy-in by showcasing the strategic value of SOA while having very clear roadmap to move towards SOA journey. This would eventually help the Organisation to achieve the business value of SOA collectively.
Even though all these are good to have, Governance is KEY to SOA. Through an on-going governance process, organisations need to measure how far one is from the SOA goals and what is going good or bad. Accordingly, decide what is to be enhanced to address those which are not going in the expected way and move towards success.
Hope I have provided some useful thoughts on how to avoid known mistakes in a SOA programme. In my subsequent blogs, I will cover where and how to start SOA journey.
]]>
Decryption, Application of XACML policies, routing to different SOAP services: 1050 messages of 7.64 KB processed per second
Legacy to SOA Integration use case: 980 messages per second for a healthcare HL7 format messages
Mediation use case: 5184 messages per second, including validation, transformation, SOAP message generation.
What additional windows of opportunity do XML appliances of such speed open up?Are there areas where XML formerly could not compete, but now can?
]]>
What it really means that our reference architecture of enterprise business automation will be truly complete where BPM will be in the driving seat and SOA will be the magic behind the machinery operating underneath. Today, BPM, SOA, EAI, B2B etc. all are reasonably fragmented and are trying to create the big picture for the enterprise in their small world..(what a contrast!)…in my story, this big pictures of the small worlds will slowly dissolve and the true big picture will emerge where all small words exist in integrated manner, in the place where they belong. And naturally, BPM will have the business impact measurements as the KPIs which will percolate into all layers beneath, be it SOA or ESB or EAI or B2B.
In my assessment, this has started happening already in pockets and it may not take more than another 2-3 years before it comes true in grand way.
]]>In some companies SOA has been oversold, or may be premature. For example, Security and Fine Grained Entitlements are so critical in some financial institutions, that without this piece in place, it may be premature to talk about SOA. Or may be the data still exists in silos, making it impossible to construct meaningful useful services, that address the immediate business needs of the organization.
But if you are under pressure to be supportive of SOA and XML, here are some ways.
]]> 10. We use ant based builds, and our build files are in XML. Therefore XML And SOA has penetrated our enterprise.
9. We use XML based configuration files for our application servers.
8. Some of our JMS messages are XML based, Others use Map Messages, but we could convert them to XML easily.
7. We are using industry standard canonical models, they are in XML. The canonical model covers only a small part of our business, but if a better canonical model for our particular industry, and for the way we do things was available we would use XML.
6. We have business rules engine package, and the rules are stored in XML
5. We have some reports generated in XML before they are converted to PDF automatically.
4. We have an ESB, and 2% of our messaging traffic, goes through the ESB.
3. 0.4 % of the traffic is in XML.
2. One application routes its messages dynamically in XML
1. We recently upgraded to Office 2007, so even when we write a Word document, we are using XML.
The last point about Office documents being in XML and therefore "SOA compliant" could perhaps be perspicacious and visionary rather than facetious and tongue-in-cheek.
Consider a law firm or a pharmaceutical research group, or a financial services companies- or even a transportation and logistics company, that gets all its customer/supplier documents in Office 2007 format- where does the knowledge critical to the business reside?
In another blog, I will try to show you how even if your enthusiasm for SOA is limited to potentially saving your Word 2007 document in XML form- you could still be moments away on the SOA bandwagon.
]]>
Is it necessary to have an advanced and mature SOA Stack in order to have centralized security policy creation and enforcement? If a SOA Stack is not at a stage where Composite Applications are proliferating, is centralized security still required?
You need centralized security policy creation and enforcementet quite early in your SOA program. The first step in your SOA initiative will be to decide what level of granularity your services should be at. It is very easy to create webservices using built-in wizards found in many IDEs as well as wizards offered in products like databases and portals.
]]>This leads to service proliferation, leading to a “Forest of Services”. The best practice therefore is to create coarse grained services, with the service mapping to an enterprise level entity like “Customer” or “Supplier”.
This immediately creates a security issue.
If all of the customer information, including sensitive private information is in the same XML object, how can I enforce security? How can I enforce role based security? Where should role and enterprise policy based security be administered from?
For example, you may say that only people “Sales Manager” and above, are authorized to view past customer purchase information. Only “Customer Support Manager- Level III” and above, can see customer private information. Remember, this is not about encryption but “View Privelege”.
It is possible to enforce this in custom code at the service level, but that would be a maintenance nightmare. If you want to change policy and give access to Customer Private Information to all “Customer Support Manager- Level II”, it would require a code, or at least a XML configuration file change, and service redeployment, with all its problems(Finding a maintenance window everyone can agree on, Obtaining builds before the Maintenance window in order to test them)
Changing policies at the centralized level is much simpler.
Does IBM have solutions to help with this?
Yes, IBM as well as other vendors, have solutions to protect XML data at the field level. This is not about encryption of the data, but about granting the privilege of accessing the data at the field level, based on organizational role and enterprise security policy. For example: Forum Systems , IBM DataPower Layer 7 have appliances that can protect data at the field level.
XML Security can also be implemented using ESB level mediation in application servers such as Websphere.
What about Database level security that is role or Enterprise rule based?
Oracle has a product called “Oracle Virtual Private Database” that can enforce database security at the Enterprise level. DB2 has “Label based Access Control” which does not appear to be as flexible as Oracle VPD. These products need to be integrated into the SOA Security Reference Architecture.
So where is the gap in the IBM SOA Security Reference Architecture?
The gap is that the Security Reference Architecture does not provide a way to leverage the technologies above. Additional Architecture Building Blogs are needed to create a scalable, Performant, maintainable, extensible and standards based way of administering Enterprise Security in the SOA Context. It should support central administration with security policy delegation.
Why can I not use Tivoli Federated Security?
Tivoli Federated Security allows you to do single-sign on onto multiple systems. It does not provide a way of enforcing security policies at the enterprise level, or to delegation.
In the next blog entry, I will describe the missing Architecture Building Blocks in greater detail, with a Visio based diagram.