One of the initial concerns about service-oriented architecture (SOA) was that an organization had to transform...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
the entire enterprise to have meaningful SOA adoption. Many organizations saw it as an all or nothing proposition. In many cases, this led to failures because organizations did not attempt wholesale adoption, it posed too much change and was too great of a shift away from how they previously delivered applications.
Now, organizations are realizing they can accomplish more successful SOA adoption on a domain-based approach. This allows an organization to phase in SOA adoption in a meaningful and successful way.
Thomas Erl, CEO of Arcitura Education Inc. and author of several SOA-related books including SOA Design Patterns, said a key to SOA success lies in choosing a relevant domain that crosses company silos in a manageable way. A senior enterprise architect can play a main role in identifying relevant domains, making decisions and implementing the most relevant and valuable domains to begin with.
Erl explained, "The realization that we can accomplish more successful SOA adoption on a domain basis led to a complete change in how SOA was approached. It allowed SOA to be phased in. It allowed us to identify a segment of the IT enterprise where we could achieve that balance."
Creating domain-specific inventories
Creating a single enterprise service inventory can be difficult for the enterprise. If done poorly, it can jeopardize the success of the entire SOA initiative. The idea of domain inventory is that services can be grouped into domain-specific inventories that can be independently standardized, governed and managed.
Enterprise architects need to play a role in enforcing standards.
Erl has found that the main reason for using domains has to do with the business logic underlying business services. Each department may have different business and data models representing business documents, which forms the basis for drawing the boundaries and establishing separate domains.
In order for these domains to be meaningful, the services have to cross silos, said Erl. It is also important to build domains at the enterprise level so they can be managed by a centralized IT team. Each domain can be phased in as the organization transitions to SOA.
Domains may be separated based on geography, zones of authority, disparate computing environments, business segments or operational segments. Segmenting by business line could make sense for a large conglomerate representing unrelated product categories. Segmenting by operations, on the other hand, could make sense when there is a need for boundaries between operational groups such as sales, customer service, quality control and logistics.
When implementing SOA on a domain basis, the standards developed don't need to be applied globally across the enterprise. Each business unit is free to create a service for specific business processes using existing data models common to the business group, which can be individually owned and managed by various departments. Using good boundaries allows each group to keep the service inventory in sync with evolving business models with minimal impact on other domains.
Setting the stage
Enterprise architects need to play a role in enforcing standards. This will help improve successful adoption of the particular SOA project(s) and pave the way for broader SOA adoption throughout the organization. Erl said, "If SOA is new to an organization, this approach has a lower risk, and can expose the IT staff to all of the practices, technologies, design principles and patterns that come with SOA before rolling it out on a broader scale."
This is especially important for things like governance, where the IT team has to ensure that elements of what they are building can be used for services beyond the immediate need. They are delivering services with certain characteristics, which will be part of the solution as they are measured and checked. This will support not only immediate requirements, but evolving business needs. They need to be able to deliver services with the expectation that they might change.
After these boundaries have been defined, a best practice for the enterprise architect is to work with business segment managers to define data models, naming conventions and rules relevant to the particular domain. Good standards improve the ability to compose services while reducing the need for bridges between domains.
It is also important for the enterprise architect to work with different project teams to ensure services with duplicate functionality are not being developed independently throughout the organization.
There may be disparity between the services created for different business groups because they are individually standardized. Each domain may also rely on different data models, technology or versions of technology.
More on successful SOA implementation
When to combine SOA and RESTful interfaces
Manage app lifecycles using application metrics
Improving estimates with AFP specification
Tips for getting started with SOA
When it is not practical to create enterprise-wide standards, some bridging mechanism may be required to compose services together that cross domain boundaries. In these cases, you need to consider design patterns that harmonize these different services such as data model transformation, data format transformation and protocol bridging.
Using a cross domain utility layer design pattern helps provide a common infrastructure for services developed for different business groups. This layer handles transformation between domains to overcome disparities. Enterprises use it to maintain services that are technology-centric and required by multiple departments throughout the organization.
Different departments can leverage these patterns, but they must have a different governance approach for managing the services. This enables reuse of these services across domains so each department does not have to recreate them for its own domain, and the organization can use a domain-based approach without having the domains completely isolated. It also improves the potential for reuse and standardization across the domains. Reusing these services across the organization reduces development time as well.
Here are questions to consider when looking at a domain-based approach:
Who will manage the services within each enterprise segment?
Do geographic boundaries create problems for enterprisewide adoption?
Are different segments of the organization supported by different IT departments, or is IT centrally managed?
Do certain business segments have a greater need for the kind of agility that a SOA approach allows?
Do the different business segments use incompatible data models?
Are IT managers for different business segments willing to give up control over the way projects are developed?
Implementing SOA throughout the enterprise promises significant long-term benefits in terms of agility and cost savings. However, if the organization tries to take on too much at once, the efforts are likely to fail. It is a good idea to start with the low hanging fruit and identify smaller domains that are easier to implement in terms of technology, IT support and political hurdles. Early success with these projects will help pave the way for more extensive SOA projects throughout the organization.
Dig Deeper on Service-oriented architecture (SOA) implementations
George Lawton asks:
Have you considered adopting a domain-based approach to SOA?
0 ResponsesJoin the Discussion