How to build an ideal SOA team

tend to adopt SOA

The main trends in software development are the transition from traditional software architectures to service-oriented architectures (SOA). In a traditional software architecture, the project is treated as a delivery of a single new application. In SOA, projects are treated as deliverables for integrated services-some are new, some are existing. Virtually all information technology (information Technology,it) departments are currently working on transitioning to SOA, regardless of their size and budget. You may have read too many articles about SOA adoption, maturity models, and implementations. This article describes a new set of roles and responsibilities for your IT team members in the process of an organization adopting SOA or transitioning to a higher level of SOA maturity.

When the SOA team is formed, the biggest paradigm shift is the transition from composite application delivery to service delivery. Traditional software developers typically build a module in an application, or part of a single layer in a typical three-tier architecture. An example of a developer is the person who is responsible for the controller or model layer in the Model-view-controller (MODEL-VIEW-CONTROLLER,MVC) architecture. In an SOA environment, these developers are now responsible for the service implementation. They do not need to know when, how or why to invoke the service, and who invokes the service. What they are concerned about is what the service does and what service level agreements it needs to meet (AGREEMENT,SLA).

To make this paradigm shift, you need to form a complete SOA team, each of which has a slightly different responsibility than the same role in the traditional software development team. This article describes the following roles in the SOA team:

• Architects
• Development Staff
• Business Analyst
• Project Manager

There are several other roles in a typical IT organization, including infrastructure support, database support, security, and so on. However, once you know how these primary roles change, you will be able to adjust the other roles to match them.

　　 Understanding the role of architects

In larger organizations, there are usually two architectural teams. The Enterprise Architecture team defines the control policies, best practices, and processes that each application team within an organization must follow. The application Architecture team is responsible for the architecture of its particular application, ensuring that the architecture supports current and future business requirements.

　　 Enterprise Architects

In an SOA organization, the role of an enterprise Architect is to promote and promote the adoption of SOA. They need to help application architects and individual development teams understand the fundamentals of SOA and translate business requirements into meaningful services so that they can be implemented and exposed.

Services that are used only by your own application or business process are of little value. Enterprise architects need to ensure that all application architects discuss their projects on a regular basis to determine which services they can expose or use. In situations where existing services cannot be reused, enterprise architects also need to ensure that every opportunity to build new services is fully exploited. Promoting reuse of existing services is certainly a higher priority than writing new services. Finally, they must recognize that services are built on reliable technology and that they can meet established SLAs.

The Enterprise Architect is responsible for defining the mechanism for determining and tracking SLAs. They define policies and procedures for control, security, disaster recovery, and so on. They are usually the main decision-makers involved in WEB services management, orchestration, and Enterprise service bus solutions.

　　 Application Architects

The role of the application architect is to ensure that the code being written is service-oriented and follows best practices and processes that can be used for service-oriented development. They need to translate business requirements into meaningful services without overly designing the solution. Typical service creation and use is more expensive than direct invocation of code. Therefore, determining the level of granularity that is exposed as a service and how to expose it is the primary job function of the role.

The application architect also works closely with the enterprise architects and other application architects in the organization to ensure that each service reuse opportunity is fully utilized, and that services are properly built, discovered, securely protected, used, and measured.

The application architect is ultimately responsible for all technical aspects of service delivery and use (non-functional requirements), including the ability to determine SLA compliance, compliance with control policies, implementation and security policy, and so on.

When reading information about architects in different SOA literature, you may encounter the term business architect, the person who should understand the business situation and design the service. In my SOA team definition, the work of this role is done by the application architect, not by the Enterprise Architect. The application architect or business architect is the coordinator for technical design between the business team and the technical team, and the business analyst is the coordinator for the business.

Role of developer

In traditional IT groups, developers are typically responsible for a fragment of the application. These fragments can be either functional (such as a registry or report module) or technology (such as JavaServer Pages?). [JSP], Enterprise JavaBeans [EJB], database layer, and so on.

Because SOA teams typically adopt shorter development cycles, it is impractical to divide developers by technology. As a result, it is easier to shift the development team divided by functionality to the new SOA developer role.

Successful SOA developers will be able to understand both business processes and capabilities at the same time. They will properly build the services they need to meet the needs of business processes. It is increasingly important to perform good design principles for error handling, tracking/auditing, data transformation, and security, and to ensure that it is added to any service code. Because one of the core tenets of SOA is reuse, developers must abandon the idea that traditional developers want to build everything. If an aspect of the service already exists, please use the service-not build it yourself.

Because of the technical development of WEB services and the availability of a large number of reference materials on the technology, developers are "heavily armed" enough to be fully qualified for their work in the new SOA environment.

　　 the role of the business analyst

Business analysts may be one of the hardest roles to get the right understanding. As a technician and architect, I tend to view the architect as the most critical SOA team member. However, based on experience and the most prudent consideration, I must point out that, as a member of the SOA team, the business analyst actually has the most change in the job. Regardless of the development environment, business analysts perform two main functions:

Communicate with executives and policy level users to understand their requirements for the system.

Communicates with technical team members to translate identified requirements into technical specifications that can be coded and tested.

In an SOA environment, business analysts have two new functions:

Work with the entire development team and let them start thinking in a service way. What services do they need to work on? What services exist that are available for use or are being used after adjustment. Mailroom )

Work with the technical team to design and build the necessary services that may take advantage of existing services that already exist.

Whether you like it or not, business analysts often change the requirements in many enterprises due to the limitations of the technologies that the organization uses. This problem may not be eliminated, but in an SOA environment, the business analyst must have more room for service design without worrying too much about technology.

　　 the role of the project manager

The main difference between the role of a project manager in an SOA environment and that of a project manager in a traditional IT environment is the project lifecycle. Regardless of what approach the SOA team uses (IBM Rational?) Unified Process (RUP), waterfall, agile approach), project managers often need to plan a shorter delivery cycle for each service. They define service level agreements (SLAs) with business users and different service consumers. In addition, they must work with multiple IT teams, such as the infrastructure support team, to ensure that these SLAs are achievable.

The role of project managers in coordinating and tracking services while they are running is more important than tracking day-to-day service delivery. However, the job is relatively easy because of the shorter cycle.

　　 Summary: SOA roles and their implications for your team

　　The key words discussed in this article are training. When you decide to conduct an SOA project, you need to carefully consider the current roles of the team and ensure that they are ready to work in the SOA through training, mentoring, and tuning trials and error cycles.