Adopting, designing, and governing SOA well

SOA Best Practices Digest

Subscribe to SOA Best Practices Digest: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SOA Best Practices Digest: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


SOA Best Practices Authors: Jason Bloomberg, Andy Thurai, Charles Araujo, Hollis Tibbetts, Pat Romanski

Related Topics: Enterprise Architecture, SOA Best Practices Digest, SOA in the Cloud Expo, CIO/CTO Update, VITO Report

VITO Report : Blog Feed Post

The Role of the Business Analyst in an SOA World

The problem arises because SOA models functionality of a business across multiple boundaries

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.

Read the original blog entry...

More Stories By JP Morgenthal

JP Morgenthal is a veteran IT solutions executive and Distinguished Engineer with CSC. He has been delivering IT services to business leaders for the past 30 years and is a recognized thought-leader in applying emerging technology for business growth and innovation. JP's strengths center around transformation and modernization leveraging next generation platforms and technologies. He has held technical executive roles in multiple businesses including: CTO, Chief Architect and Founder/CEO. Areas of expertise for JP include strategy, architecture, application development, infrastructure and operations, cloud computing, DevOps, and integration. JP is a published author with four trade publications with his most recent being “Cloud Computing: Assessing the Risks”. JP holds both a Masters and Bachelors of Science in Computer Science from Hofstra University.