… nobody is doing enterprise architecture. The truth of this bold statement is quite obvious when you think about it. Where does enterprise architecture take place today? In enterprises, of course. That is, existing enterprises. And you don’t architect things that already exist. Architecture comes before you build something! Can you imagine hiring an architect after building a bridge or a building?

It’s a fine point. He goes on to say that instead, architects try to fix what’s broken using best practices and yadda yadda – it’s way more interesting to EAs, I’m sure. But here’s the rub: There are a slew of comments, some of which purport to agree then add a big “but” while others outright disagree.

Read the entire article at http://www.itbusinessedge.com/cm/blogs/lawson/enterprise-architecture-paying-off-at-del-monte/?cs=46661.

In his new post Jason Bloomberg is asking a question “Why Nobody is Doing Enterprise Architecture ?” He notes that:

A solution architect architects a solution before that solution is implemented. A Java architect or a .NET architect does their work before the coders do theirs. You don’t build and then design, you design and then build… Enterprise architecture, on the other hand, always begins with an existing enterprise… The role of today’s enterprise architect is essentially to take the current enterprise and fix it. OK, maybe not the whole thing, but to make some kind of improvement to it. Go from today’s sorry state to some future nirvana state where things are better somehow.

Read the entire post at http://www.infoq.com/news/2011/04/EnterpriseArchitecture.

[Jason] Bloomberg: The integration story is a rather tricky. On the one hand, integration problems lead to SOA discussions because you have this rat’s nest of complexity in these large organizations where integration now becomes the key challenge. Maintaining a complex integration environment can be enormously expensive and inflexible.

That being said, taking an architectural approach is basically starting at the other end of the problem, saying, “How can we organize IT resources so that we don’t have to think about integration in a traditional way.” Instead, we can focus on building services and supporting flexible composition of services and essentially we get the benefits of integration as a result of service composition.

Read more at http://www.itbusinessedge.com/cm/community/features/interviews/blog/as-soa-matures-guidelines-clear-up-about-when-and-where-to-use-it/?cs=40316

I followed up with [Jason] Bloomberg recently to ask him what he meant by “SOA plus other things.” Here’s what he said: “It’s important to realize that SOA is really a rather loose collection of best practices. It’s not necessarily a well-defined list where you have some checklist of things to do SOA and if you miss one, you’re not doing SOA. What’s happening is architecture teams are incorporating SOA best practices into various other initiatives. … So we’re seeing a lot of SOA best practices in cloud computing and master data management and other areas, BPM, where the projects may not be identified as SOA projects, but they’re leveraging SOA best practices as, essentially, established architecture best practices.”

Read more at http://www.itbusinessedge.com/cm/blogs/lawson/soa-spending-on-the-rise-surprised-heres-why/?cs=40313

Lawson: You participated in a Briefings Direct Analyst podcast earlier this year on what to expect in 2010, and one of the things you discussed was “SOA plus other things?” What did you mean by that?

Bloomberg: It’s important to realize that SOA is really a rather loose collection of best practices. It’s not necessarily a well-defined list where you have some checklist of things to do SOA and if you miss one, you’re not doing SOA. What’s happening is architecture teams are incorporating SOA best practices into various other initiatives. It may not be identified as an SOA initiative. So we’re seeing a lot of SOA best practices in cloud computing and master data management and other areas, BPM, where the projects may not be identified as SOA projects, but they’re leveraging SOA best practices as, essentially, established architecture best practices.

Read more at http://www.itbusinessedge.com/cm/community/features/interviews/blog/putting-soa-to-work-with-mdm-and-bpm/?cs=40162.

Read more at http://www.sdtimes.com/link/34062 .

Upon further consideration, the true answer lies somewhere in between these extremes. Now, we’re not reconsidering the conclusions of the Process Isomorphism ZapFlash. Rather, further explanation and clarification is warranted. As with any best practice, Process Isomorphism doesn’t apply in every situation, and not every Service should correspond to a process task or subtask. That being said, there is also a good chance that some of our esteemed fellow pundits might not be opining from a truly Service-oriented perspective, as many of their comments hint at an object-oriented (OO) bias that may be too limiting in the SOA context. In fact, understanding which Services the Process Isomorphism pattern applies to, and how other Services support such Services goes to the heart of how to think about Services from a SOA perspective.

The Object-Oriented Context for Services

In the early days of Web Services, as various standards committee members tried to hash out how core standards should support the vision of SOA, the SOAP standard for message transport was an acronym for the “Simple Object Access Protocol.” The reasoning at the time was that Services were interfaces to objects, and hence Service operations should correspond to object methods, also known as remote procedures. SOAP was nothing more than a simple, XML-based way of access those methods. Over time, however, people realized that taking this Remote Procedure Call (RPC) approach to Service interfaces is too limiting: it leads to tightly coupled, synchronous interactions that constrain the benefits such Services could offer. Instead, the industry settled on document style as being the preferred interface style, which expects requests and responses to conform to schemas that are included in the Service contracts by reference, where the underlying Service logic is responsible for validating interactions against the relevant schemas.

Document style interfaces provide greater loose coupling than their RPC-style cousins because many changes to a Service need not adversely impact existing Service consumers, and furthermore, document style interfaces facilitate asynchronous interactions where a request need not correlate immediately with a response. In fact, the W3C eventually dropped the “Simple Object Access Protocol” definition of SOAP altogether, and now SOAP is just SOAP, instead of being an abbreviation of anything.

However, document style interfaces still allow for operations, only now they’re optional rather than mandatory as is the case with RPC-style interfaces. The fact that operations are optional is a never-ending sense of confusion for students in our Licensed ZapThink Architect course, perhaps because of the object-oriented pattern of thinking many of today’s techies follow, often without realizing it. How would you ever know what a Service is supposed to do, the reasoning goes, if you don’t call an operation on that Service? The answer is straightforward: if a Service has no operations, then what it’s supposed to do is understood from the context of the Service itself. For example, an insurance company may want a Service that simply approves a pending insurance policy. If we have an approvePolicy Service, the consumer can simply request that Service with the policy number of the policy it wants to approve.

Nouns vs. Verbs

The insurance policy example brings up a fundamental question. Which is the Service, the insurance policy entity or the approve policy task? In other words, should Services be nouns or verbs? It’s possible to design Services either way, as Entity Services, which predictably represent business entities, or as Task Services, that represent specific actions that implement some step in a process, in other words, verbs. Which approach is better?

If you look at the question of whether Services should be nouns or verbs from the OO perspective, then Services are little more than interfaces to objects, and hence it’s best to think of Services as nouns and their operations as the verbs. For example, following the OO approach, we might have an insurance policy object with several operations, including one that approves the policy, as the following pseudocode illustrates:

myPolicy = new Policy ();
…
successOrFailure = myPolicy.approve ();

The first statement above instantiates a particular policy, while the second one approves it, and returns either success or failure.

Now, it is certainly possible to create a Policy Service as an Entity Service that has an approve operation that works more or less like the example above, with one fundamental difference: because Services are fundamentally stateless, you don’t instantiate them. Here, then, is pseudocode that represents how an Entity Service would tackle the same functionality:

request to create new policy, specifying create policy operation –> Policy Service –> response with policy number 12345
…
request to approve policy 12345, specifying approve policy operation –> Policy Service –> response with success or failure

Note that we’re representing Service interactions as input and output messages that contain documents, where in this case, the input documents specify operations. In this example, there is no object in the OO sense representing policy 12345 and maintaining the state information that indicates whether or not that particular policy is approved or not. Instead, the underlying Service implementation maintains the state information. There is only the one Policy Service, and it accepts requests in the form of XML documents and returns responses, also in the form of XML documents. If a request calls the create policy operation, then the Policy Service knows to create the policy, while a request that specifies the approve policy operation follows the same pattern.

Note that the fact that the Policy Service has a document style interface gives us two advantages: first, we can make certain changes to the Service like adding new operations without adversely impacting existing consumers, and second, its stateless nature enables asynchronous interactions, where instead of returning success or failure of the approve request, perhaps, the Service returns a simple acknowledgement of the request (or perhaps no response at all), and then notifies the consumer at some point in the future that the policy has been approved, either through a one-way notification event or possibly as a response to a further query.

Task Services as Verbs

While there is a significant role for Entity Services in SOA, it is important to break free from OO-centric thinking and consider other types of Services as well that serve other purposes. In fact, there is another way of offering the same functionality as the Entity Service above where the Services represent verbs rather than nouns, what we call Task Services. Here is the pseudocode for this situation:

request to create new policy –> createNewPolicy Service –> response with policy number 12345
…
request to approve policy 12345 — > approvePolicy Service –> response with success or failure

In this example, neither Task Service has any operations, but rather the functionality of each Service is understood from the context of the Service. After all, what would an approvePolicy Service do but approve policies? If you read the Process Isomorphism ZapFlash, the benefits of delivering capabilities as Task Services is clear. If you design each Task Service to represent tasks or subtasks in business processes, then it’s possible to build a Service-Oriented Business Application (SOBA) that is isomorphic to the process it implements.

Combining Entity and Task Services

A casual reading of the Process Isomorphism ZapFlash might lead you to think we were suggesting that all Services should be Task Services. However, in spite of the fact that architects with OO backgrounds often rely too heavily on Entity Services, such Services do play a critical role in most SOA implementations. Remember that in the enterprise context, Services expose existing, legacy capabilities and data that are typically scattered across different applications and data stores, limiting the enterprise’s agility and leading to high integration maintenance costs, poor data quality, reduced customer value, and other ills all too familiar to anybody working within a large organization’s IT department. SOA provides best practices for addressing such issues by abstracting such legacy capabilities in order to support flexible business processes.

Both Entity and Task Services help architects connect the dots between legacy capabilities on the one hand, and flexible process requirements on the other, as the figure below illustrates:

Process, Task, and Entity Service Layers

In the figure above, the bottom row contains Entity Services, which directly abstract underlying legacy capabilities. Above the Entity Services lie the Task Services, which may actually be abstractions of individual operations belonging to underlying Entity Services. The top layer contains Process Services, which are typically compositions of Task Services. In other words, Process Services are interfaces to SOBAs, and when those SOBAs are compositions of properly designed Task Services, they will exhibit process isomorphism.

The essential question for the architect is which capabilities to abstract in which Service layer. Take for example the Address Change Task Service. Changing addresses is a common example of a particularly challenging task in many large organizations, because address information is typically maintained by different applications and data stores in a haphazard, inconsistent manner. To make matters worse, there may be addresses associated with customers, policies, or other business entities.

When architecting the Customer Entity Service, the core design principle is to pull together the various instances of customer-related information and functionality across the as-is legacy environment into a single, consolidated representation. Such a Service will likely have an update address operation, and the Customer Entity Service’s logic will encapsulate whatever individual queries and API calls are necessary to properly update customers’ addresses across all relevant systems.

The Address Change Task Service, then, abstracts the Customer Entity Service’s update address operation, as well as whatever other address change operations other Entity Services might have. The Service logic behind this Task Service understands, for example, that insured properties in polices have addresses and customers have addresses, and these addresses are related in a particular way, but are by no means equivalent.

The ZapThink Take

As is usually the case, architects have several options at their disposal, and knowing which option is appropriate often depends on the business problem, an example of the “right tool for the job” principle. If the business problem is process-centric, say, a need to streamline or optimize the policy issuance process, then implementing SOBAs as compositions of Task Services will facilitate process flexibility. In other cases, the business problem is more information-centric than process-centric, for example, putting consolidated customer information on a call center rep’s screen. In such instances the architect’s focus may be on an Entity Service, because the rep is dealing with a particular customer and must be able to interact with that customer in a flexible way.

The big picture of the SOA architect’s challenge, of course, is delivering agility in the face of heterogeneity. On the one hand, the IT shop contains a patchwork of legacy resources, and on the other hand, the business requires increasingly agile processes. Understanding which capabilities belong in Entity Services and which belong in Task Services is a critical part of the best practice approach to SOA.Download File