With 24-hours a day, unceasing news being forced in our ears and down our throats, with computers that blog, phones that text and everything that twitters, we have information rushing back and forth at us at speeds that can only be measured in nanoseconds. It is information on steroids and it can and often does get us in trouble. Analyzing, corroborating, vetting and authenticating this rush of information, misinformation and hyperinformation are at times almost impossible.
Ladies and Gentleman of the class of 2011, adopt SOA. If I could offer you only one tip for the future, SOA would be it. The long term benefits of SOA may not yet have been proven and my advice has no basis more reliable than my own meandering experience. I will dispense this advice now.
I know many of you are still trying to get to grips with Service Oriented Architecture (SOA), so apologies in advance for the potential mental exertion and confusion of introducing Business Oriented Architecture (BOA).
For projects that may well be delivered by Service Oriented Architecture (possibly using Service Oriented Analysis), I would suggest that you may need to consider different or additional ways of documenting your requirements and specifications. The reason for this is that the way you shape your requirements needs to encompass both the holistic nature of SOA, as well as the new terminology and delivery mechanisms.
Although you can do ‘standard’ requirements gathering for Service Oriented Architecture (SOA) projects, there is now an evolving a set of analysis techniques, methods and approaches that purport to be better suited to information gathering and design specification. I will call these generically Service Oriented Analysis.
We are often asked what you need to do to run a successful SOA Pilot. Based on our experience of dozens of pilots, I propose that the following characteristics are essential to success.
It is unfortunate, but not surprising, that the elegant and relatively simple view of SOA has become bloated with a bewildering array of methodologies and products, leading to confusion and bafflement by many of its proponents and potential converts.
So far in this column on SOA for Analysts, I have talked about the use and re-use of services as building blocks to put together new or better business applications. Now you are getting familiar with this concept, I need to peel away a layer of the SOA onion and expose you to a few tears by revealing this as a half-truth.
We are witnessing a marked increase in both the importance of and focus on the work of the business analyst that is directly proportional to the depth with which cloud computing services are utilized. What's more, we are experiencing a shift in the tools and skills that our analysts and those of our customers are required to utilize.
Anyone perusing the computing rags (or their online equivalents) will no doubt have noticed that this year's big thing for applications development is a combination of Cloud Computing and Software as a Service (SaaS). I'll talk about Clouds in a future blog, as I want to concentrate on the SaaS phenomenon today.
Much of the current buzz about SOA has been focussed on the technology (inevitably Web Services) or the importance of reusability. However the real value of SOA is in the improvement to processes and ways of working that reflect the alignment of an organisation with its customers and suppliers. The approach we favour is one that begins by aligning the business and technical understanding of the concepts of SOA, from both the business process and technical architecture perspective.
Most analysts are introduced to SOA in one of three ways; two of which are potentially painful and one of which is actually useful. I’ll let you decide which you would prefer.
In the last article I covered the term Service to death. In this one I want to go through a number of other SOA Three Letter Acronyms and terms that you may come across and for which you would like to be able to nod knowingly.
Like any other religion, sorry architecture, SOA has its own language and meanings for the terms it uses. Unfortunately, some of these words can be very confusing, none more than the term "service". So here is a bluffer's guide to understanding and conversing in SOA-speak.
In this SOA article I would like to begin by defining what SOA is and what you need to know about it. In future articles, I will explore some of the challenges and benefits of SOA to the analyst community. Let’s start off with a definition of SOA. You can, of course, look at a number of definitions of SOA on the Web, but you will find them confusing and contradictory as there are a number of views on this ranging from SOA is everything, to SOA is just Web Services, neither of which is true.
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us