The SOA Killer App ZapFlash
By Jason Bloomberg
Document ID: ZAPFLASH-200653 | Document Type: ZapFlash
Back in 2003, when ZapThink wrote our SOA Tools and Best Practices report, we first encountered a problem that we hadn't seen when we wrote our Web Services Security, Service-Oriented Management, and XML Appliances reports. The problem we ran into with our SOA Tools report was that the market was so immature that there weren't any tools specific to Service-Oriented Architecture (SOA) available yet. In that report, we explored a number of related tools markets, to be sure, including modeling tools, rapid application development tools, integrated development environments (IDEs), business process modeling/management (BPM) suites, and more -- but no vendor had yet developed a tool specific to the tasks inherent in implementing SOA.
In the intervening three years, SOA tools have matured significantly. Tool vendors have made substantial progress building SOA-specific products, to be sure, but even now the SOA tools on the market are still limited in their capabilities. We've recently seen some model-driven declarative application tools, a healthy crop of policy management/governance tools, the recent emergence of Service-oriented business application (SOBA) composition tools, and even some SOA-specific testing products, to name a few. But the market has still not delivered a single product that brings together all of the capabilities we called for in our 2003 report into a single, Service-oriented tool.
We don't mean to fault any of the SOA tools vendors out there, because after all, the market is only now beginning to demand the SOA tool that we're calling for. If such a product had existed in the market in 2003, it would have been too far ahead of existing demand, and its vendor might have found itself lacking sufficient runway to continue development until customers were ready for such a product. Today, however, the demand for such a comprehensive tool is emerging, and the requirements and characteristics of this sort of tool are now becoming clearer.
Furthermore, by exploring the necessary capabilities for SOA tools, it's possible to get a better picture of what it means to be an application in the Service-oriented world. It's important to realize that the sort of tool companies require to build Service-oriented applications is not a simplistic extension of the concept of an IDE to the world of Web Services, such as Gartner's ill-fated "Integrated Service Environment" idea of a couple of years back. Instead, we're describing a new kind of tool that is itself a new kind of application -- a tool that promises to disrupt the current tools space and define a new market in the process. There's a term for such applications that so radically redefine their market -- a killer app. This ZapFlash, therefore, focuses on what we'll call the SOA Killer App.
SOA Killer App as Modeling Tool
The SOA Killer App must first and foremost be an architecture tool, naturally, since SOA is first and foremost architecture. The central architectural model of SOA is the Service model, which is an abstract representation of both the Services in production as well as the requirements for new or modified Services. The SOA infrastructure then actualizes the Service model with contract, policy, and other metadata that allow for the declarative configuration the Services over time.
The SOA Killer App must therefore be a modeling tool -- but not a typical design time modeling tool. Rather, in SOA, it's essential for architects to maintain the Service model at runtime and change time as well, and thus there must be a feedback loop that connects the management environment with the models in the tool. Enterprise architects, among others, will use the SOA Killer App during all phases of the Service lifecycle.
One reason the SOA Killer App is so elusive is that many people struggle with the concept of models, because models are abstract representations, but nobody says what that abstract representation is supposed to be. Should it be a flowchart in an application? A UML sequence diagram? A description written in a natural language? Maybe a set of rules? In fact, these representations are among many possibly appropriate representations, depending upon the person using the modeling tool and the particular task at hand. The SOA Killer App should be able to switch seamlessly among any such representations to afford the greatest flexibility to the greatest number of people within the organization.
SOA introduces another wrinkle to the traditional modeling tool concept. Since Service-oriented processes are composed of Services and exposed as Services, the SOA Killer App must also provide BPM capabilities, as well. It must handle well-defined orchestrations that consist of sequences of process steps with predefined flows, as well as more ad hoc processes defined as choreographies that only specify preconditions and postconditions for interaction in a non-programmatic manner. The SOA Killer App should support the declarative nature of the SOBAs it models, and it must automatically maintain an accurate representation of the processes in production, even as they undergo changes.
Soup to Nuts SOA Lifecycle
The SOA Killer App is far more than a modeling tool, however. It must provide flexible, diverse capabilities for all members of the SOA lifecycle team, including Service-oriented (enterprise) architects, technical architects, business analysts, Service developers, Service consumer developers, information and data architects, quality assurance personnel, the operations team, as well as the support staff. Each of these roles has different responsibilities and expectations for the tools they use, and the SOA Killer App must provide the appropriate capabilities for each person on the team.
With such a diverse and powerful set of capabilities, however, comes the increased risk of people really mucking things up, either accidentally or intentionally. To mitigate such risks, the SOA Killer App must also provide core governance capabilities. Governance, in fact, is one of the hot button issues in SOA today. Comprehensive governance capabilities include the creation and communication of corporate policies, as well as tools for following and enforcing those policies, gaining visibility into the levels of policy compliance, as well as an approach to mitigating any deviations from policy. For the SOA Killer App to provide broad capabilities for a diverse team with varied responsibilities, the tool must support the policy creation, management, and enforcement that today's SOA governance tools provide. In the Service-oriented context, companies will want to handle governance declaratively, just as they want to handle business process and Service configuration. The SOA Killer App must therefore provide the capabilities that policy managers require, and must even allow for the creation of meta-policies -- the policies in an organization that apply to the creation, communication, and enforcement of policies.
The Mother of all Dashboards
the visibility into policy compliance companies require for effective governance is only one small part of the visibility requirement that companies have today. As companies adopt SOA as their enterprise architecture, all forms of visibility into the data in the organization as well as the workings of all parts of the IT environment will fall under the core Service abstraction that underlies SOA. The SOA Killer App will therefore roll together all of today's various dashboards, including system management dashboards, business intelligence applications, information technology service management (ITSM) and business service management (BSM) tools, identity and access management (IAM) dashboards, and more.
Today, the word "service" has different meanings in different contexts, but as SOA becomes prevalent, these various definitions of service will converge. No longer will the various dashboards in the organization present siloed data in a siloed manner. The SOA Killer App will bring them together, provide new approaches for combining the knowledge each one provides, and enable various people within the organization to take action on the information they glean from this improved dashboard. In fact, the SOA Killer App will replace the traditional, inflexible portal altogether over time.
The Universal Service Consumer
Browser interfaces like those of today's portals are only one example of the wide variety of Service consumer applications people are using to leverage the capabilities of Services. As today's software vendors increasingly leverage the power of SOA in their consumer products, however, it will become clear that many of today's diverse applications are examples of a single, broad class of consuming application, including desktop applications like spreadsheets, business process tools, and Rich Internet Applications (RIAs). What, after all, makes a desktop app different from a RIA? Today's desktop apps almost universally access the Internet, and the RIAs people are now building with technologies like asynchronous JavaScript and XML (AJAX) and Flash can do everything a desktop app can do. A glimpse into the inner workings of Windows Vista shows how blurred the distinction between desktop apps and RIAs is becoming, and the Java and open source worlds are keeping pace. Soon there will be no salient difference.
There is something much more fundamental going on here than the rise of AJAX and other technologies for building a wider variety of applications. Remember, in the Service-oriented world, applications are compositions of Services built declaratively using tools like the SOA Killer App. The fact that technologies like AJAX, Flash, and Java Server Faces allow us to leverage a page metaphor, a streaming media metaphor, or a rich application metaphor whenever appropriate breaks down the walls between one application and another, and even makes it impossible to count the number of applications in any situation. If every Web page is an application, and stringing several Web pages together is also an application, then what is an application, and how many applications do you have?
The ZapThink Take
If tomorrow's application is basically an enterprise mashup, which is a flexible composition of Services in the context of a governance framework, then what about the SOA Killer App itself? Yes, it's an enterprise mashup as well. There will never be just one SOA Killer App, since after all, the idea of having a any particular number of applications is no longer a relevant concept. We spoke of the SOA Killer App as containing modeling and development capabilities, a wide range of dashboards, and the capabilities of every Service consumer under the sun. But that doesn't mean that you'd expect to buy such a thing as a shrink-wrapped package from a single vendor. Instead, the SOA Killer App enables the creation and evolution of itself as a composition of Services -- an enterprise mashup tool that is itself an enterprise mashup.
This profoundly bootstrapped nature of the SOA Killer App is perhaps the deeper reason we haven't seen one on the market yet. After all, the first one cannot be built with itself, but rather with more traditional tools. Once the first SOA Killer App hits the market, however, then companies will be able to use it to evolve what it means to be a SOA Killer App. At that point, the tool will truly be a killer app, in that it will transform the market it participates in, along with what it means to be an application.
Document ID: ZAPFLASH-200653 | Document Type: ZapFlash
Back in 2003, when ZapThink wrote our SOA Tools and Best Practices report, we first encountered a problem that we hadn't seen when we wrote our Web Services Security, Service-Oriented Management, and XML Appliances reports. The problem we ran into with our SOA Tools report was that the market was so immature that there weren't any tools specific to Service-Oriented Architecture (SOA) available yet. In that report, we explored a number of related tools markets, to be sure, including modeling tools, rapid application development tools, integrated development environments (IDEs), business process modeling/management (BPM) suites, and more -- but no vendor had yet developed a tool specific to the tasks inherent in implementing SOA.
In the intervening three years, SOA tools have matured significantly. Tool vendors have made substantial progress building SOA-specific products, to be sure, but even now the SOA tools on the market are still limited in their capabilities. We've recently seen some model-driven declarative application tools, a healthy crop of policy management/governance tools, the recent emergence of Service-oriented business application (SOBA) composition tools, and even some SOA-specific testing products, to name a few. But the market has still not delivered a single product that brings together all of the capabilities we called for in our 2003 report into a single, Service-oriented tool.
We don't mean to fault any of the SOA tools vendors out there, because after all, the market is only now beginning to demand the SOA tool that we're calling for. If such a product had existed in the market in 2003, it would have been too far ahead of existing demand, and its vendor might have found itself lacking sufficient runway to continue development until customers were ready for such a product. Today, however, the demand for such a comprehensive tool is emerging, and the requirements and characteristics of this sort of tool are now becoming clearer.
Furthermore, by exploring the necessary capabilities for SOA tools, it's possible to get a better picture of what it means to be an application in the Service-oriented world. It's important to realize that the sort of tool companies require to build Service-oriented applications is not a simplistic extension of the concept of an IDE to the world of Web Services, such as Gartner's ill-fated "Integrated Service Environment" idea of a couple of years back. Instead, we're describing a new kind of tool that is itself a new kind of application -- a tool that promises to disrupt the current tools space and define a new market in the process. There's a term for such applications that so radically redefine their market -- a killer app. This ZapFlash, therefore, focuses on what we'll call the SOA Killer App.
SOA Killer App as Modeling Tool
The SOA Killer App must first and foremost be an architecture tool, naturally, since SOA is first and foremost architecture. The central architectural model of SOA is the Service model, which is an abstract representation of both the Services in production as well as the requirements for new or modified Services. The SOA infrastructure then actualizes the Service model with contract, policy, and other metadata that allow for the declarative configuration the Services over time.
The SOA Killer App must therefore be a modeling tool -- but not a typical design time modeling tool. Rather, in SOA, it's essential for architects to maintain the Service model at runtime and change time as well, and thus there must be a feedback loop that connects the management environment with the models in the tool. Enterprise architects, among others, will use the SOA Killer App during all phases of the Service lifecycle.
One reason the SOA Killer App is so elusive is that many people struggle with the concept of models, because models are abstract representations, but nobody says what that abstract representation is supposed to be. Should it be a flowchart in an application? A UML sequence diagram? A description written in a natural language? Maybe a set of rules? In fact, these representations are among many possibly appropriate representations, depending upon the person using the modeling tool and the particular task at hand. The SOA Killer App should be able to switch seamlessly among any such representations to afford the greatest flexibility to the greatest number of people within the organization.
SOA introduces another wrinkle to the traditional modeling tool concept. Since Service-oriented processes are composed of Services and exposed as Services, the SOA Killer App must also provide BPM capabilities, as well. It must handle well-defined orchestrations that consist of sequences of process steps with predefined flows, as well as more ad hoc processes defined as choreographies that only specify preconditions and postconditions for interaction in a non-programmatic manner. The SOA Killer App should support the declarative nature of the SOBAs it models, and it must automatically maintain an accurate representation of the processes in production, even as they undergo changes.
Soup to Nuts SOA Lifecycle
The SOA Killer App is far more than a modeling tool, however. It must provide flexible, diverse capabilities for all members of the SOA lifecycle team, including Service-oriented (enterprise) architects, technical architects, business analysts, Service developers, Service consumer developers, information and data architects, quality assurance personnel, the operations team, as well as the support staff. Each of these roles has different responsibilities and expectations for the tools they use, and the SOA Killer App must provide the appropriate capabilities for each person on the team.
With such a diverse and powerful set of capabilities, however, comes the increased risk of people really mucking things up, either accidentally or intentionally. To mitigate such risks, the SOA Killer App must also provide core governance capabilities. Governance, in fact, is one of the hot button issues in SOA today. Comprehensive governance capabilities include the creation and communication of corporate policies, as well as tools for following and enforcing those policies, gaining visibility into the levels of policy compliance, as well as an approach to mitigating any deviations from policy. For the SOA Killer App to provide broad capabilities for a diverse team with varied responsibilities, the tool must support the policy creation, management, and enforcement that today's SOA governance tools provide. In the Service-oriented context, companies will want to handle governance declaratively, just as they want to handle business process and Service configuration. The SOA Killer App must therefore provide the capabilities that policy managers require, and must even allow for the creation of meta-policies -- the policies in an organization that apply to the creation, communication, and enforcement of policies.
The Mother of all Dashboards
the visibility into policy compliance companies require for effective governance is only one small part of the visibility requirement that companies have today. As companies adopt SOA as their enterprise architecture, all forms of visibility into the data in the organization as well as the workings of all parts of the IT environment will fall under the core Service abstraction that underlies SOA. The SOA Killer App will therefore roll together all of today's various dashboards, including system management dashboards, business intelligence applications, information technology service management (ITSM) and business service management (BSM) tools, identity and access management (IAM) dashboards, and more.
Today, the word "service" has different meanings in different contexts, but as SOA becomes prevalent, these various definitions of service will converge. No longer will the various dashboards in the organization present siloed data in a siloed manner. The SOA Killer App will bring them together, provide new approaches for combining the knowledge each one provides, and enable various people within the organization to take action on the information they glean from this improved dashboard. In fact, the SOA Killer App will replace the traditional, inflexible portal altogether over time.
The Universal Service Consumer
Browser interfaces like those of today's portals are only one example of the wide variety of Service consumer applications people are using to leverage the capabilities of Services. As today's software vendors increasingly leverage the power of SOA in their consumer products, however, it will become clear that many of today's diverse applications are examples of a single, broad class of consuming application, including desktop applications like spreadsheets, business process tools, and Rich Internet Applications (RIAs). What, after all, makes a desktop app different from a RIA? Today's desktop apps almost universally access the Internet, and the RIAs people are now building with technologies like asynchronous JavaScript and XML (AJAX) and Flash can do everything a desktop app can do. A glimpse into the inner workings of Windows Vista shows how blurred the distinction between desktop apps and RIAs is becoming, and the Java and open source worlds are keeping pace. Soon there will be no salient difference.
There is something much more fundamental going on here than the rise of AJAX and other technologies for building a wider variety of applications. Remember, in the Service-oriented world, applications are compositions of Services built declaratively using tools like the SOA Killer App. The fact that technologies like AJAX, Flash, and Java Server Faces allow us to leverage a page metaphor, a streaming media metaphor, or a rich application metaphor whenever appropriate breaks down the walls between one application and another, and even makes it impossible to count the number of applications in any situation. If every Web page is an application, and stringing several Web pages together is also an application, then what is an application, and how many applications do you have?
The ZapThink Take
If tomorrow's application is basically an enterprise mashup, which is a flexible composition of Services in the context of a governance framework, then what about the SOA Killer App itself? Yes, it's an enterprise mashup as well. There will never be just one SOA Killer App, since after all, the idea of having a any particular number of applications is no longer a relevant concept. We spoke of the SOA Killer App as containing modeling and development capabilities, a wide range of dashboards, and the capabilities of every Service consumer under the sun. But that doesn't mean that you'd expect to buy such a thing as a shrink-wrapped package from a single vendor. Instead, the SOA Killer App enables the creation and evolution of itself as a composition of Services -- an enterprise mashup tool that is itself an enterprise mashup.
This profoundly bootstrapped nature of the SOA Killer App is perhaps the deeper reason we haven't seen one on the market yet. After all, the first one cannot be built with itself, but rather with more traditional tools. Once the first SOA Killer App hits the market, however, then companies will be able to use it to evolve what it means to be a SOA Killer App. At that point, the tool will truly be a killer app, in that it will transform the market it participates in, along with what it means to be an application.
Comments