The Business Analyst vs. the Enterprise Architect
As adoption of Service-Oriented Architecture (SOA) spreads in the enterprise, one of the most notable trends in the market, other than introduction of new products and services, are changes to the organizational structure of businesses that are successful with SOA. In addition to the growth of Centers of Excellence (CoE) and competency centers focused on SOA, we’re also seeing a greater focus on enterprise architecture (EA) groups that lead and guide SOA initiatives across the organization. However, EA groups are not alone in trying to help meet the wide range of needs of the business with IT solutions. Indeed, before the discipline of EA got the visibility it has now, another part of the organization held sway with the business — business analysts.
Business analysts serve an important role in the organization, helping to marry the needs of the business with the various capabilities and resources available to it. However, now that the EA organization is getting its time in the limelight, what will happen to traditional business analysis and the business analyst organization? Are BAs a separate group that should be given a specific role in interacting with EA groups and SOA efforts, or are business analysts simply another type of enterprise architect that should be rolled into SOA initiatives? Furthermore, what’s the future of the business analyst? In this ZapFlash, we hope to bring the business analyst and enterprise architect roles into sharper focus so that we can help the organization maximize its resources for business success.
What is the role of a Business Analyst?
In order to understand how the roles of business analyst and enterprise architect might interact, we first need to understand what exactly a business analyst does. Wikipedia defines a business analyst (BA) as a person who practices the discipline of business analysis. Obviously. More insightfully, the entry continues: “A BA is responsible for analyzing the business needs of their clients to help identify business problems and propose solutions. Within the systems development life cycle domain, the business analyst typically performs a liaison function between the business side of an enterprise and the providers of services to the enterprise. Common alternative titles are business systems analyst, systems analyst, and functional analyst, although some organizations may differentiate between these titles and corresponding responsibilities.” Reading between the lines it seems that a business analyst is responsible for translating the needs of the business into specifics that can be acted upon by individual parts of the business.
Reinforcing this definition, the International Institute of Business Analysis clarifies that “a business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.” To be relevant then to the area that EAs concern themselves with, we really are focusing on one sort of BA in particular: the IT business analyst.
An article on CIO.com refines the role of the IT business analyst as the organization that scopes the system, interprets business need, translates technical issues into language that business can understand, scopes out the project details and requirements, serves as the liaison between the development team and business representatives, helps the project team traverse the politics of the organization, creates test cases and scenarios, and acts as advocates for project stakeholders. In this regard, a business analyst isn’t a project manager per se, however they function as the business requirements role necessary in every IT project.
What makes the BA role interesting is that it predates the predominant use of IT in the enterprise. In the days before IT, the BA would have a set of principles and methods they would use to address risk management, facilitate inter-organizational communication, improve labor utilization, optimize processes, and perform other tasks that required connecting the strategic aspects of the business with the tactical parts that made it work. When IT was introduced into the mix, it just became another part of the mechanism that made things “work”.
Conflict and cooperation with the role of an Enterprise Architect
At first blush, it seems that much of the responsibility of IT BAs overlaps with the responsibility of EAs. In a number of previous ZapFlashes, we defined the role of an EA as providing executive-level management leadership to all architecture efforts across the enterprise, pulling together and establishing core architectural best practices for the entire organization, establishing business-focused Service Domains that bring together Business Services that share a common business context, creating, coordinating, and funding teams to run the Service Domains on behalf of the lines of business as well as IT, working closely with the VP of Project Management to insure close cooperation between architecture and project management teams, and to improve project management policies, and working closely with executive management within each line of business to communicate the process improvement and agility benefits of the SOA initiative, to coordinate process definition, improvement, and management activities, and to better align IT capabilities with business needs overall, among other responsibilities. And to make matters worse for the BA, according to Payscale.com, an average BA with 5-9 years of experience makes a bit less than $66k a year, while EAs with equal experience make over $100k.
Furthermore, in our discussion of the SOA Metamodel, we defined the EA as the person, or organization, that shepherds business requirements into Services and then manages the realization of those Services through the IT development organization. In this light, it would seem that the role of the EA eclipses, competes, or otherwise impedes the efforts of the BA in the organization. So, are the BA and EA different roles trying to accomplish similar tasks? Not exactly.
Even if we focus on the role of an IT Business Analyst, it is clear that the scope of the work and nature of their skills differ in significant ways. An EA’s role is to translate business requirements into capabilities that can be cost-effectively implemented, predictably managed, and reliably controlled. The central abstraction for the EA is the Service Model and other models that relate to information, process, system, and functional flow to enable the ongoing operation of the business. As abstract as this may seem, especially to developers, the BA acts at an even more abstract level.
BAs are primarily tasked with requirements generation and facilitation of communications with technical groups to make sure those requirements are reliably implemented. In this regards, while an EA has both feet firmly planted on both sides of the business-IT divide, the BA (even an IT BA) is weighted towards the business.
Most organizations separate the roles of the BA and EA. However, organizations that are looking to maximize the benefit they receive from SOA and other architecturally-driven IT efforts should think more holistically about either combining the EA and BA responsibilities in the business or creating a new organizational structure that puts the business analysis and enterprise architecture roles into more intimate contact.
Part of the reason for bringing BA and EA closer together is that BAs often lack the technical skills to do the modeling part that is so necessary to making good architecture work. Second, most BAs have business metrics in mind (as they should) without having visibility into how IT will impact the realization of those metrics. Furthermore, BAs still think in terms of discrete business needs that need to be addressed in short timeframes. To achieve the promised SOA goals of reuse, reduction of redundancy, and business agility, the EA can provide the corporate memory and long-term strategic IT planning that most BAs lack in their tactical approach to today’s business needs.
The ZapThink Take
In most organizations, the role of the BA is far more developed and understood than the role of the EA. As such, it would be unreasonable to assume that the EA role will usurp, replace, or otherwise impinge on existing BA capabilities. However, the future of EA and the future BA are clearly moving in complementary directions. To the extent that BAs are dealing more and more with requirements for agility, reuse, and reduced cost of integration, they will find themselves mirroring the activities of the EA groups in their organization. Likewise, the more that EAs find themselves responsible for translating ill-defined business requirements into architectural models and Service definitions, the more they will find themselves filling a BA role in the organization.
Clearly, not everything in the organization that a BA will deal with is IT centric, and likewise, the EA organization won’t cover all aspects of business operation. However, we’re in a business environment that’s looking to squeeze every bit of value and inefficiency out of IT. In this environment, it only makes sense to rethink the role of the BA and EA together — an expanded, strategic, and operational role for IT planning that plays more in the hands of business than it does in the increasingly commoditized hands of IT implementation and operations. When this happens, architecture itself becomes strategic and can move out of the hands of the IT organization and into the hands of business operations.