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.
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.
If the object you are trying to create is so simple that you can see it in its entirety at a glance and remember how all of its components fit together at excruciating level of detail all at one time, you don’t need Architecture. You can "wing it" and see if it works. It is only when the object you are trying to create is complex to the extent that you can’t see and remember all the details of the implementation at once, and only when you want to accommodate on-going change to the instantiated object, that Architecture is IMPERATIVE. Once again, without Architecture, you are not going to be able to create an object of any complexity and you won’t be able to change it (that is, change it in minimum time, with minimum disruption and minimum cost).
Two years ago, some of my friends pressed me intensely to be more definitive about the Framework concepts. Even though, I had written “The Book”, they were specifically asking me for definitions of the entities that comprise the metamodel of Row 2 of the Enterprise Framework. It has taken me and a team of dedicated folks two years, however we have progressed far beyond the original requirement.
Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics? Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: