The prevailing evolution in software development is moving from traditional software architecture to Service-Oriented Architecture (SOA). In traditional software architecture, you think of a project as the delivery of a single new application. In SOA, you think of a project as the delivery of integrated services -- some new, some existing. Almost every information technology (IT) shop, regardless of size and budget, is currently moving toward SOA. You've probably read several articles about SOA adoption, maturity models, and implementation. This article describes the new set of roles and responsibilities that members of your IT team need to take on as your organization adopts SOA or moves to a higher level of SOA maturity.
When forming an SOA team, the biggest paradigm shift is moving from composite application delivery to the delivery of services. Traditional software developers generally build either a module within an application or a portion of a single layer in typical three-tier architecture. An example is developers who are responsible for the controller or model layers in a Model-View-Controller (MVC) architecture. In the SOA environment, those developers are now responsible for service implementations. They do not need to know when, how, or why the services are invoked or who invokes them. All they care about is what the services do and which Service Level Agreements (SLAs) they need to comply with.
To make this paradigm shift, you need to form an entire SOA team for which each role changes slightly from that same role in a traditional software development team. This article shows you how the following key roles fit into an SOA team:
- Architects
- Developers
- Business analysts
- Project managers
There are several more roles in a typical IT organization, including infrastructure support, database support, security, and so on. However, when you understand how these key roles change, you'll be able to adjust the remaining roles to match them.
Understanding the role of architects
In larger organizations, there are typically two architecture groups. The enterprise architecture group defines the governing policies, best practices, and procedures that each application group within the organization must follow. The application architecture group is responsible for the architecture of their specific applications and ensuring that the architecture can support current and future business needs.
In an SOA organization, the role of enterprise architects is to promote and foster the adoption of SOA. They need to help application architects and development groups understand the fundamentals of SOA and translate business requirements into meaningful services that those groups can implement and expose.
There is little value in services that are used by only your own application or business process. Enterprise architects need to ensure that all the application architects are discussing their projects on a regular basis to identify services that they can expose or consume. In cases where an existing service cannot be reused, enterprise architects also need to make sure that every opportunity to build a new service is exploited. Fostering the reuse of existing services is definitely a higher priority then writing a new one. Finally, they must confirm that services are built on sound technology and are capable of meeting the established SLAs.
Enterprise architects are responsible for defining mechanisms to measure and track SLAs. They define policies and procedures around governance, security, disaster recovery, and so on. They are typically key decision makers for solutions involving Web services management, orchestration, and Enterprise Service Bus.
The role of application architects is to make sure that the code being written is service oriented and follows the best practices and processes available for service-oriented development. They need to translate business requirements into meaningful services without over-engineering the solutions. Typical service creation and consumption is more costly than the straight invocation of code. Thus, determining the level of granularity in what to expose as a service and how to expose it is a key job function of this role.
Application architects also work closely with the enterprise architects and other application architects in the organization to make sure that every opportunity for service reuse is being exploited and that the services are properly built, discovered, secured, used, and measured.
Application architects are ultimately responsible for all the technical aspects of service delivery and consumption (non-functional requirements), including measurability of adherence to SLAs, meeting governance policies, enforcing and ensuring security polices, and so on.
When reading about architects in different SOA literature, you might encounter the term business architect, meaning someone who is supposed to understand the business and design the services. In my definition of SOA teams, this role is filled by the application architects, not the enterprise architects. The application or business architects are the intermediaries between the business and technology groups for the technical design aspects, whereas business analysts are the intermediaries for the business aspects.
In traditional IT groups, developers typically work on a segment of the application. Those segments may be determined by functionality (such as a registration or reporting module) or technology (such as JavaServer Pages® [JSP], Enterprise JavaBeans [EJB], database tier, and so on).
Because of the short development cycles typically used by SOA teams, division of developers by technology is impractical. Therefore, it is easier to migrate development teams that are divided by functionality to the new SOA developer roles.
Successful SOA developers understand business processes and functionality. They appropriately build the services required to satisfy the business processes. It becomes increasingly important to enforce good design principles for error handling, tracking/auditing, data translation, and security, and to make sure they are incorporated into any service code. Because one of the core principles of SOA is reuse, developers have to let go of the typical developer desire to build everything. If a service already exists for something, use it -- don't reinvent it.
Given the technological advancements of Web services and all the reference materials around the technology, developers are probably the best equipped to perform their jobs in the new SOA environment.
The business analyst is probably one of the toughest roles to get right. As a technical person and an architect, I tend to think of architects as the most critical SOA team members. However, based on experience and most careful thought, I must say that it is actually business analysts whose jobs change the most as part of an SOA team. There are two key functions business analysts perform, regardless of development environment:
- Communication with executives and users at a strategic level to understand their requirements for the system.
- Communication with the technical team members to transform the established requirements into technical specifications that can be coded and tested to.
In an SOA environment, business analysts have two new functions:
- Work with the entire development team to get them to start thinking in terms of services. (What services do they need to do their jobs? What services already exist that they can use or tweak and use? And so on.)
- Work with the technical team to design and build the necessary services, potentially leveraging services that already exist.
Like it or not, in many companies business analysts often change requirements because of limitations of the technologies used by the organization. This issue might not go away, but in an SOA environment business analysts definitely have more room to design services without worrying as much about technology.
The key difference between the role of project managers in an SOA environment compared with those in a traditional IT environment is the project life cycle. Regardless of what methodology you follow -- IBM Rational® Unified Process (RUP), waterfall, agile -- on an SOA team, project managers typically need to plan for shorter delivery cycles for each service. They work with the business users and different customers of services to define service-level agreements (SLAs). In addition, they must work with several IT groups, such as infrastructure support, to make sure that the SLAs are attainable.
The role of project managers in coordination and tracking of services as they are running becomes more important than tracking day-to-day service delivery. However, this is easier because the cycles are shorter.
Summary: SOA roles and what they mean to your team
The key word in this discussion is training. When you decide to embark on a SOA project, you need to think carefully about the current roles of the people on your team and make sure they are well equipped to perform the SOA versions of their roles through training, mentoring, and adjusting your trial and error cycles.
Learn
- Visit the developerWorks SOA and Web services zone to learn more about SOA.
- Stay current with developerWorks technical events and webcasts.
Get products and technologies
- Build your next development project with IBM trial software, available for download directly from developerWorks.
Discuss
- Participate in developerWorks
blogs and get involved in the developerWorks community.
- Share your information architecture experiences and confer with other information architects in the developerWorks IT architecture forum.
Kunal Mittal is a consultant specializing in Java technology, J2EE, and Web services technologies. He is the coauthor of, and has contributed to, several books on these topics. He works as a director within the Domestic TV IT group for Sony Pictures Entertainment, where he's responsible for the technical architecture and management of applications for that division. In his spare time he writes for IBM developerWorks, consults on SOA, and is a private pilot. For more information, visit Kunal's Web site at www.kunalmittal.com or contact him at kunal@kunalmittal.com.
