Those of us that are part of SOA-related projects where traditional business analysts (BA) are involved often find ourselves frustrated by the incongruence between the analyst’s approach to requirements gathering and the SOA design. The problem arises because SOA models functionality of a business across multiple boundaries, whereas the business analyst wants to focus on a user’s needs. One focus is tactical and the other is strategic. However, more than this key difference, certain aspects of the tactical requirements overlap with the strategic requirements; specifically with regard to service boundaries. Thus, important business rules that are relevant to the definition of a particular service are buried among hundreds of irrelevant (to the SOA goals) requirements and the SOA architect is forced to mine these requirements like a miner mining for gold.
In figuring that someone else must have written on this topic, I visited my favorite Web search engine and pulled up the following article: “The new business analyst talks SOA”. I was surprised to find this content on Network World given the nature of the topic, but quickly realized that the author thought of SOA as an application architecture instead of an aspect of Enterprise Architecture. So, it was not much more of a surprise when they recommended that business analysts needed to become more savvy in SOA by learning BPEL, SCA and SDO; perhaps the worst advice I have ever seen regarding this topic. The last thing we want are the business analysts talking about SOA, let alone SODA aspects of SOA.
Still, the article had one point correct, business analysts had better be reading the signs and acclimating themselves to a different type of conversation with their users. Moreover, I believe SOA is a game changer in the way that we collect requirements going forward. For businesses that really want to be successful with SOA, the first conversations that need to be had are with the key business stakeholders, and an Enterprise Architect with SOA experience must be present and facilitating these discussions. This will be the basis for formulating a service model, which will then guide all future system designs. I would also engage a business process engineer to start analysis of business processes that directly impact the effort.
Ultimately, if a BA is able to make the transition to SOA mindset, then they might be a good candidate to drill down and analyze the requirements for the service contract and vocabulary for each service. Otherwise, an SOA architect should really handle these efforts. Which begs the question, what is the role of the BA in an SOA world? I believe there is a need for really good subject matter experts that can work with the Enterprise and SOA architects to fully define the interactions between business functions and, perhaps, to capture the usability models. However, even in the case of usability, a usability expert will offer more insight into how to present information to the user than the BA.
Overall, my analysis is that in an SOA universe, the role of the BA is greatly diminished unless they can adapt to the change in role and gain an understanding of how to facilitate requirements gathering in a much more compartmentalized manner as outlined by the SOA architect and the business process engineer.
Can you elaborate or point to some resources describing the outline for requirements gathering that an SOA Architect might follow?
Excellent post! I think there are real challenges in bringing business analysts into the service development lifecycle. SOA projects can surely leverage a business analyst’s domain expertise while bringing in the technology strategy, business process agility, and loosely coupled aspects of service-orientation. I wrote a post on this topic highlighting the need for analysts to focus on the needs and not on the design and implementation.
JP, Good to see your views on this happening topic. I agree that SOA is a game changer in the way we collect requirements. I would even go a step ahead and add that it would gradually change the way the stakeholders and business users express requirements. In my opinion, requirements does not start from business analysts, but from business stakeholders and business users. BA’s skillfully extract it (IT teams may differ on this based on expectations/experience) and document them for teams downstream. Service requirements are no different, though there is widespread lack of enablers to present such requirements in expected format. Requirement recording tools, revised document formats/checklists and service inventory trackers are few of such enablers. BPM tools (Like those from ARIS, now part of Software AG) are classic examples of such enablers. They enable BA’s to identify new services to be created, while also highlighting existing services that are to be reused as such or with change.
Lately, there have been thoughts floated around Enterprise/SOA Architects stepping more in to business analysis (http://www.itbusinessedge.com/cm/blogs/lawson/can-enterprise-architects-align-it-to-the-business-yeah-right/?cs=36310) or Business Analysts getting the tech edge. I have seen traction with the former approach in various enterprises, though there are limitations to both these approaches. In a SOA environment, both roles would need to co-exist, though with a better understanding and appreciation for each other’s contributions. I highlighted this in a recent article (http://www.infoq.com/articles/soa-service-identification).
Diminishing BA role (If not for a change from within) is not good for an enterprise engaged in SOA and not an option, I’m afraid. Rather, business stakeholders should emphasize on the need for the new approach while providing appropriate toolset (Methodologies like Agile wouldn’t have come this far if not for this). IT should facilitate and be in the feedback loop to get what they want and how they want.
Interestingly enough, in my SOA Vision, a hypothetical SOA enterprise does very well without even an IT budget for development!
I don’t think the BA role needs to change much to facilitate SOA. At the project level, where BAs operate, SOA is a tactical discipline that belongs in the hands of the technical team. As representatives of the business, BAs are primarily concerned with managing requirements from the customer’s point of view. They, like the customer, should not be vested in the implementation, just the delivered solution. It is the responsibility of the technical team–the architects and engineers–to translate the BA’s business and functional requirements into appropriate service implementations.
That said, BAs can grease the SOA skids by 1) engaging in regular feedback loops with technical teams, 2) pushing back on customer demands that run contrary to the broader SOA strategy, and 3) developing clear SLAs, OLAs, and KPIs that can be accounted for in service design.
I don’t believe SOA is a “game changer” when it comes to the role of the business analysts, and I would caution against them having SOA discussions with non-IT stakeholders, but SOA certainly brings an added dimension to solution development that BAs should be cognizant of.
Marc,
Your response is predicated on your belief that SOA is ever a tactical discipline, for which I have to strongly disagree. SOA is always a strategic discipline, mapped into tactical deliverables. Also, SOA does NOT belong in the hands of a technical team. I don’t know why you believe that SOA a) has anything fundamentally to do with technology or b) is tactical in nature, but no where is this viewpoint agreed upon by the major thought leaders on SOA.
JP
Not sure what you mean by “SOA is ever a tactical discipline” but my position is that SOA is strategic at the executive and EA level and becomes tactical at the point where services need to be developed. (SOA never stops being a strategic discipline, but tactical implementation needs to agree with that strategy. To me, this extends SOA into the technical realm. Not moves. Extends.) I agree unwaveringly that SOA has nothing fundamentally to with technology, but technology is assumed to be applied at some point. So my question is this: If technical teams are not involved in SOA, who builds the service interfaces, data transformations, and integration components? Surely not the CIO.
Exactly, not the CIO and not the BA either. This is why we need SOA architects to handle this.
Which supports my statement that architects and engineers are responsible for transforming BA deliverables into deployed services–arguably a tactical activity. It seems technical folks do have a hand in delivering SOA after all.
For me, not exactly. It’s one of the reasons I favor Gartner’s disambiguation of SOA & SODA. There’s a process for taking SOA designs and applying them to systems development; I call that SODA. To be clear, this is a transformative process; the results of the SODA effort are an approximate or an interpretation of the design, not the SOA itself. The differentiation is critical and often overlooked, but more importantly, leads to dissolutionment by management when they don’t obtain the SOA benefits and don’t understand the cause.
[…] via The Role of The Business Analyst in an SOA World « The Tech Evangelist. […]
You touched on HealthCare. In the context of Cloud Computing, Vivek Kundra the nation’s new visionary CIO, has suggested he will push the federal government towards Cloud Computing and off-the-shelf software wherever possible. The question is will payors and providers exit the field where they are in a scrum and the patient is the ball. Vendors will continue to generally push where opportunity exists, precisely in the moment.
The promise of Cloud Computing to United States Healthcare should be the focus of savings to the federal government versus the spending plan that is so much in focus right now.
Too bad that the OMB, the office of the CIO and the HHS secretary are not weighing in on Healthcare reform from a business optimization and enterprise architecture perspective.
Maybe they are, and we just don’t know it.
Noted: Your comments on the ‘funding dilemma’