Words like "SOA", "ESB", "EDA" are common and, unfortunately, extremely abused. In summary, below a one page description of the main buzzwords floating around.
Architectural Styles
SOA is an architectural style aimed to create a conceptual framework and a collection of practices to improve the alignment of IT to core business needs. SOA is not about technologies. At its core there is the concept of Service, which is an abstract interface to a concrete business function, for example: logistics management, HR & recruiting, stock control, order management, invoicing, ... A Service implementation is governed by a policy, exposes an end-point, implements a defined contract and sends / receives messages. A service is transactionally atomic by definition, otherwise it's a process, which actually is about atomic services orchestration, so a very different and higher-level concept than service itself.
ESB is an architectural style aimed to highly decouple clients form service implementations, by creating an uniquely identifiable space where service policies can be applied uniformly and managed consistently.
SOI Service Oriented Integration is an evolution of classical EAI concepts, introducing an higher level of decoupling among applications by connecting abstract interfaces defined by service contracts instead of mere point to point connectivity usually happening within EAI traditional solutions. SOI = EAI + SOA.
EDA Event Driven Architecture is an architectural style which is the evolution of previous MOM techniques toward SOA concepts, by using one-way asynchronous message exchange patterns. It is a way to model the typical real-time, asynchronous system interactions happening in the real world. Routing, filtering, pipe-lining of messages are the typical tasks of an EDA, activities like CEP (Complex Event Processing) are sometimes necessary.
In Conclusions
Architectural styles and practices are the "what", "who", and "why" of a solution, they shouldn't be confused with technologies, which are the mere "how". Still we read around or listen to people who think that to make his/her IT infrastructure better and more fashionable they need to implement a bunch of SOAP Web-Services + some BPEL orchestration... That is deadly wrong and has driven the acronym SOA to be abused and inflationed and a lot of projects to fail.
Updates: yesterday Paul forwarded me this very interesting article about how Bechtel Corporation is implementing a huge SOA effort to create an internal SaaS infratructure.
Showing posts with label SOA. Show all posts
Showing posts with label SOA. Show all posts
Monday, January 12, 2009
Wednesday, January 7, 2009
The word “SOA” is dead
As usual Anne Thomas Manes wrote a brilliant and controversial article about SOA:
"Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.
But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services."
I humbly wrote something similar before, I was discussing about governance needs but the problems are almost the same:
"IT is broken: we clearly see this simple and true fact daily, but I hardly find organizations able to recognize the fact that they need to reconcile their IT operations with their business needs first through organizational changes. They too often just try to buy the next magical box and hope that plugging it into their IT department it will fix problems.
Again and as usual: lot of money, few successes and SOA is becoming another abused bad word."
However the concrete requirement, as Anne wrote, is still here and unresolved.
Updates
Anne's article is creating a lot of discussions on blogs, here time by time I will collect some of the most interesting reactions.
Steve Jones's In a recession its even more about the services:
"Reading between the lines of what Anne writes I think I'd say that her statement is that vendors are moving away from SOA as they've flogged you enough stuff and now they want to flog you its offspring: mashups, BPM, SaaS, Cloud Computing
[...]
the marketing fury of T-SOA has moved on as their just aren't that many more ESBs and Web Service tools that you can be sold.
[...]
If you adopt the new technologies without having a services mentality then you will create a degree of mess that will make the one that consultants and vendors got fat on with EAI look like a trivial problem. Doing Spaghetti inside your firewall in big applications is one thing, doing it over the internet and with thousands of small ones is a completely different scale of problem.
So in a recession you need to Identify your services, understand the business value that they deliver, understand the cost model to deliver that value and then decide on the right technology approach.
If that isn't SOA then I don't know what is. So in reality its the "other" SOA that is dead, not the SOA of today."
Yes, that's the point: vendors are looking for the next cash cow. But if you don't want to be treat like a cow you shouldn't behave like a cow and stop eating all the hypes vendors are always throwing around. SOA is actually a good thing, but it is not something new and does not require special tools unless you have all your requirements clear. Is really SOA that different from old object-oriented domain modelling? Isn't that about clean separation of public interfaces from their implementations?
A deep and savy analysis is presented by Gary Barnett:
Gary writes:
"Architecture is pivotal to the success of service based IT. It’s not a “nice to have”, it’s a fundamental necessity. Unless we as an industry make a real commitment to architecture we’re doomed to continue to make the same mistakes we’ve been making for decades."
[...]
"Take mash-ups, as an example – Sure, you can quickly assemble some fantastic apps by simply grabbing some javascript and coding away. But there are big, big, disappointments in store for mash-up builders who assume that because it’s cool and new they don’t need to think about all those boring questions that a mature approach to architecture helps you to answer (Reliability, security, availability, scalability, re-use etc etc)."
[...]
"As growing numbers of people succeed, we’re learning (or re-learning) a host of lessons about how to deliver the agility, re-use, scalability and general goodness that a service oriented approach to software architecture, design and development can provide."
Read his complete blog article.
"Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.
But perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services."
I humbly wrote something similar before, I was discussing about governance needs but the problems are almost the same:
"IT is broken: we clearly see this simple and true fact daily, but I hardly find organizations able to recognize the fact that they need to reconcile their IT operations with their business needs first through organizational changes. They too often just try to buy the next magical box and hope that plugging it into their IT department it will fix problems.
Again and as usual: lot of money, few successes and SOA is becoming another abused bad word."
However the concrete requirement, as Anne wrote, is still here and unresolved.
Updates
Anne's article is creating a lot of discussions on blogs, here time by time I will collect some of the most interesting reactions.
Steve Jones's In a recession its even more about the services:
"Reading between the lines of what Anne writes I think I'd say that her statement is that vendors are moving away from SOA as they've flogged you enough stuff and now they want to flog you its offspring: mashups, BPM, SaaS, Cloud Computing
[...]
the marketing fury of T-SOA has moved on as their just aren't that many more ESBs and Web Service tools that you can be sold.
[...]
If you adopt the new technologies without having a services mentality then you will create a degree of mess that will make the one that consultants and vendors got fat on with EAI look like a trivial problem. Doing Spaghetti inside your firewall in big applications is one thing, doing it over the internet and with thousands of small ones is a completely different scale of problem.
So in a recession you need to Identify your services, understand the business value that they deliver, understand the cost model to deliver that value and then decide on the right technology approach.
If that isn't SOA then I don't know what is. So in reality its the "other" SOA that is dead, not the SOA of today."
Yes, that's the point: vendors are looking for the next cash cow. But if you don't want to be treat like a cow you shouldn't behave like a cow and stop eating all the hypes vendors are always throwing around. SOA is actually a good thing, but it is not something new and does not require special tools unless you have all your requirements clear. Is really SOA that different from old object-oriented domain modelling? Isn't that about clean separation of public interfaces from their implementations?
A deep and savy analysis is presented by Gary Barnett:
Essentially - this is what I have to say -
- Saying “SOA is Dead” is as meaningful as saying “Art is dead”
- It is either misleading or foolish (or both) to state that SOA is dead
- Giving up on architecture just because it’s a “chore” is the road to failure…
- If SOA is dead, then Web 2.0 is dead
- The good news, though, is that SOA is as fit as a fiddle
- The bad news is that if you want to succeed, you have to be willing to make an effort
- We have a simple choice: get it right, or do it all over again
Gary writes:
"Architecture is pivotal to the success of service based IT. It’s not a “nice to have”, it’s a fundamental necessity. Unless we as an industry make a real commitment to architecture we’re doomed to continue to make the same mistakes we’ve been making for decades."
[...]
"Take mash-ups, as an example – Sure, you can quickly assemble some fantastic apps by simply grabbing some javascript and coding away. But there are big, big, disappointments in store for mash-up builders who assume that because it’s cool and new they don’t need to think about all those boring questions that a mature approach to architecture helps you to answer (Reliability, security, availability, scalability, re-use etc etc)."
[...]
"As growing numbers of people succeed, we’re learning (or re-learning) a host of lessons about how to deliver the agility, re-use, scalability and general goodness that a service oriented approach to software architecture, design and development can provide."
Read his complete blog article.
Friday, December 26, 2008
Services Virtualization and the Need for Lifecycle Management
Introduction
What I personally call "Natural Requirements" (NR) are requirements not coming from end users, analysts or marketing people. Natural Requirements are often more operational than functional or technical, let me call the latter "static requirements", and I mean the one we usually capture in the early phases of the requirements gathering process. NR instead derive from the natural and time-dependant evolution of a system well after the systems has been built and put into production. NR are naturally imposed by the environment, the context and by the fact that systems are always evolving and requires a lot of maintenance, and there is nothing we can do to eliminate them: instead we need to deal with them from a strategic standpoint, looking at the long run.
A SOA is made of a collection of interacting business services, each one with its own history and evolution. Starting from domain and data models, services defines an atomic and well identified piece of data, algorithmic result or a combination of both. Services creates a public API, they expose internal technical artefacts as integrated business, higher-level information. We (almost) all know what the SOA objectives are, so it is not interesting to repeat them here.
Natural Requirements for Service Virtualization
Services anyway pose a maintenance problem: they evolve, need to be monitored and policies have to be enforced. A public API, once published, can't be changed easily, as it is a public contract and we cannot control how many clients and how they make use of the API. When we change a public API we know that we are going to break contracts with clients, and clients need to be changed to adapt to the new interfaces.
A first Natural Requirement is that services have to be versioned to reach a level of backward compatibility. For this purpose, modern SOA Governance solutions offer not only a Registry but also a Repository - ideally a combination of both - where service interfaces and messages can be versioned to avoid breaking contracts when things change. Each client can point to the proper version of the same service and related messages.
Services implements business logic atomic features, but in their lifecycle they also deal with other orthogonal concerns, which are not functional in their nature: Policies, End point definitions, messages structure manipulation and message formats are all non-business aspects.
So Separation of Concerns is one of the main and most frequent Natural Requirement we could ever encounter in our daily routine as SOA architects. Orthogonal concerns must be consistently keep divided from business logic and other aspects. For example, one of the most common orthogonal concerns we must split from business logic is Security. For the sake of this discussion, we could identify a couple of concrete technical ways to implement services: SOAP messages over HTTP and REST Web Services. The first are usually secured by using some complex WS-Security implementation, the latter by simpler HTTP usual methods, such as basic authentication + SSL. Policy enforcement and core services must be kept separated, business logic developers shouldn't have to know that such a thing like WS-Security even exists.
"Composite applications must have the business logic defined separately from each application's infrastructure. For example, instead of baking security semantics into the code, use an external, general-purpose security framework. This will be your template for enforcing authentication and authorization rules based on declarative policies that specify the required security semantics for the service within the context of a specific application."
Services Virtualization is usually defined as a virtual view (much like a database view, at least conceptually) of a real serviced managed through a policy. A Policy is a declarative (not-programmatic) set of administrative tasks. For example you can have authentication, authorization and generally speaking access management policies. Or you can define a set of minimal performances level policies in terms of SLAs. Or then you can have billing policies for your services (think at Amazon's web services) based on volumes or number of calls.
Natural Requirements for PLM
SOA implies that business services and Composite Applications (CA) have to be handled like real products, so PLM (Product Lifecycle Management) issues and practices apply. Many vendors now offers (almost) comprehensive governance solutions which embrace policies + registry + artifacts repository and all the related versioning, but that's not enough. Governance solutions are platforms, but PLM is about the product and the process. Services needs to be created as the building blocks for CA, so they are part of the product lifecycle: the final product is the CA, while services are the components, which can be re-assembled and mixed to create other CA.
The main steps are:
Phase 1: Conceive
Imagine, Specify, Plan, Innovate
Phase 2: Design
Describe, Define, Develop, Test, Analyse and Validate
Phase 3: Realize
Manufacture, Make, Build, Procure, Produce, Sell and Deliver
Phase 4: Service
Use, Operate, Maintain, Support, Sustain, Phase-out, Retire, Recycle and Disposal
Why we should talk about PLM and not about ALM (Application lifecycle management)? ALM is just about software, while PLM is about manufacturing, so the first acronym sounds more natural. Because applications are monolithic, they are not composite in the same terms we use when building a product in manufacture. The roads to assemble a Composite Application are somehow different from Application ones, actually they are closer to manufacturing processes. The reason is that we want to create a predictable and repeatable assembly chain for services. ALM is really a subset of PLM: the Use, Operate, Maintain, Support, Sustain, Phase-out, Retire, Recycle and Disposal activities of Phase 4 needs to be operated at the level of each single Service and not at the Application level only. When we talk about SOA, services (the building blocks) are way more crucial than the resulting Composite Applications, like reliable foundations are for a house.
The Model T's body is joined to its chassis at the Highland Park plant
When we think again about the manufacturing metaphor, and specifically about car manufactures, we could assimilate the car as the final product of an assembly of other products. Let's say car wheels and tires has a clearly defined interface and the car maker just buys the product from another supplier. Tires producer knows its product can be assembled by a number of different clients, so it cannot make too many assumptions on the external world: they just have to respect the contract.
In conclusions, to be effective Services construction, assembly and maintenance require us to build our own assembly chain, following best PLM practices. But still best practices in this field are in their infancy.
The description of SOA I enjoy most is still Dan North's A Classic Introduction to SOA, which is additionally a very easy reading.
What I personally call "Natural Requirements" (NR) are requirements not coming from end users, analysts or marketing people. Natural Requirements are often more operational than functional or technical, let me call the latter "static requirements", and I mean the one we usually capture in the early phases of the requirements gathering process. NR instead derive from the natural and time-dependant evolution of a system well after the systems has been built and put into production. NR are naturally imposed by the environment, the context and by the fact that systems are always evolving and requires a lot of maintenance, and there is nothing we can do to eliminate them: instead we need to deal with them from a strategic standpoint, looking at the long run.
A SOA is made of a collection of interacting business services, each one with its own history and evolution. Starting from domain and data models, services defines an atomic and well identified piece of data, algorithmic result or a combination of both. Services creates a public API, they expose internal technical artefacts as integrated business, higher-level information. We (almost) all know what the SOA objectives are, so it is not interesting to repeat them here.
Natural Requirements for Service Virtualization
Services anyway pose a maintenance problem: they evolve, need to be monitored and policies have to be enforced. A public API, once published, can't be changed easily, as it is a public contract and we cannot control how many clients and how they make use of the API. When we change a public API we know that we are going to break contracts with clients, and clients need to be changed to adapt to the new interfaces.
A first Natural Requirement is that services have to be versioned to reach a level of backward compatibility. For this purpose, modern SOA Governance solutions offer not only a Registry but also a Repository - ideally a combination of both - where service interfaces and messages can be versioned to avoid breaking contracts when things change. Each client can point to the proper version of the same service and related messages.
Services implements business logic atomic features, but in their lifecycle they also deal with other orthogonal concerns, which are not functional in their nature: Policies, End point definitions, messages structure manipulation and message formats are all non-business aspects.
So Separation of Concerns is one of the main and most frequent Natural Requirement we could ever encounter in our daily routine as SOA architects. Orthogonal concerns must be consistently keep divided from business logic and other aspects. For example, one of the most common orthogonal concerns we must split from business logic is Security. For the sake of this discussion, we could identify a couple of concrete technical ways to implement services: SOAP messages over HTTP and REST Web Services. The first are usually secured by using some complex WS-Security implementation, the latter by simpler HTTP usual methods, such as basic authentication + SSL. Policy enforcement and core services must be kept separated, business logic developers shouldn't have to know that such a thing like WS-Security even exists.
"Composite applications must have the business logic defined separately from each application's infrastructure. For example, instead of baking security semantics into the code, use an external, general-purpose security framework. This will be your template for enforcing authentication and authorization rules based on declarative policies that specify the required security semantics for the service within the context of a specific application."
Services Virtualization is usually defined as a virtual view (much like a database view, at least conceptually) of a real serviced managed through a policy. A Policy is a declarative (not-programmatic) set of administrative tasks. For example you can have authentication, authorization and generally speaking access management policies. Or you can define a set of minimal performances level policies in terms of SLAs. Or then you can have billing policies for your services (think at Amazon's web services) based on volumes or number of calls.
Natural Requirements for PLM
SOA implies that business services and Composite Applications (CA) have to be handled like real products, so PLM (Product Lifecycle Management) issues and practices apply. Many vendors now offers (almost) comprehensive governance solutions which embrace policies + registry + artifacts repository and all the related versioning, but that's not enough. Governance solutions are platforms, but PLM is about the product and the process. Services needs to be created as the building blocks for CA, so they are part of the product lifecycle: the final product is the CA, while services are the components, which can be re-assembled and mixed to create other CA.
The main steps are:
Phase 1: Conceive
Imagine, Specify, Plan, Innovate
Phase 2: Design
Describe, Define, Develop, Test, Analyse and Validate
Phase 3: Realize
Manufacture, Make, Build, Procure, Produce, Sell and Deliver
Phase 4: Service
Use, Operate, Maintain, Support, Sustain, Phase-out, Retire, Recycle and Disposal
Why we should talk about PLM and not about ALM (Application lifecycle management)? ALM is just about software, while PLM is about manufacturing, so the first acronym sounds more natural. Because applications are monolithic, they are not composite in the same terms we use when building a product in manufacture. The roads to assemble a Composite Application are somehow different from Application ones, actually they are closer to manufacturing processes. The reason is that we want to create a predictable and repeatable assembly chain for services. ALM is really a subset of PLM: the Use, Operate, Maintain, Support, Sustain, Phase-out, Retire, Recycle and Disposal activities of Phase 4 needs to be operated at the level of each single Service and not at the Application level only. When we talk about SOA, services (the building blocks) are way more crucial than the resulting Composite Applications, like reliable foundations are for a house.
The Model T's body is joined to its chassis at the Highland Park plantWhen we think again about the manufacturing metaphor, and specifically about car manufactures, we could assimilate the car as the final product of an assembly of other products. Let's say car wheels and tires has a clearly defined interface and the car maker just buys the product from another supplier. Tires producer knows its product can be assembled by a number of different clients, so it cannot make too many assumptions on the external world: they just have to respect the contract.
In conclusions, to be effective Services construction, assembly and maintenance require us to build our own assembly chain, following best PLM practices. But still best practices in this field are in their infancy.
The description of SOA I enjoy most is still Dan North's A Classic Introduction to SOA, which is additionally a very easy reading.
Tuesday, September 9, 2008
What BPEL stands for?
I have been involved in several projects where one recurring request was to "use BPEL", or more generically "to implement some level of Business Process Management (BPM)". BPEL means Business Process Execution Language and the OASIS Standard defines it as:
"WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces."
An extended definition of SOA says:
"Service-oriented architectures (SOA) promise to implement composite applications
that offer location transparency and segregation of business logic. Location
transparency allows consumers and providers of services to exchange messages
without reference to one another’s concrete location. Segregation of business logic
isolates the core processes of the application from other service providers and
consumers."
(from: Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK - Sun Microsystems)
So basically BPEL allows to segregate business logic into pieces of reusable sequences of atomic business activities, expressed through an XML syntax. SeeBeyond and Sun JavaCAPS 5.1 supported the BPEL 1.x standard through the eInsight engine, while the new, opensource Sun OpenESB supports BPEL 2.0., but there are of course many other products from different vendors.
However the point is that BPEL is about "segregation of business logic", it is not about "arrow and boxes programming". I underline this because I am seeing many projects where BPEL is very misused and abused: they are kind of replacing Java with BPEL because the latter is more buzzword-oriented and all those arrows and boxes look nicer. But then it happens that resulting BPEL is just polluted by technical activities, while I'm stressing the fact it should contain pure business logic. So my hint is to always put your orthogonal concerns (logging, error handling, auditing, etc...) somewhere else and leave your BPEL as clean as possible. For example, with OpenESB (commercially aka JavaCAPS 6) there is a nice JavaEE-SE which is the JBI Service Engine to execute EJBs (practically, it is a JBI bridge to the below application server). Here is a list of all JBI components you can use, have a look at Aspect SE, Camel SE (Apache Camel Service Engine) and Scripting SE for other very interesting opportunities to avoid messing-up your business logic...
"WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces."
An extended definition of SOA says:
"Service-oriented architectures (SOA) promise to implement composite applications
that offer location transparency and segregation of business logic. Location
transparency allows consumers and providers of services to exchange messages
without reference to one another’s concrete location. Segregation of business logic
isolates the core processes of the application from other service providers and
consumers."
(from: Implementing Service-Oriented Architectures (SOA) with the Java EE 5 SDK - Sun Microsystems)
So basically BPEL allows to segregate business logic into pieces of reusable sequences of atomic business activities, expressed through an XML syntax. SeeBeyond and Sun JavaCAPS 5.1 supported the BPEL 1.x standard through the eInsight engine, while the new, opensource Sun OpenESB supports BPEL 2.0., but there are of course many other products from different vendors.
However the point is that BPEL is about "segregation of business logic", it is not about "arrow and boxes programming". I underline this because I am seeing many projects where BPEL is very misused and abused: they are kind of replacing Java with BPEL because the latter is more buzzword-oriented and all those arrows and boxes look nicer. But then it happens that resulting BPEL is just polluted by technical activities, while I'm stressing the fact it should contain pure business logic. So my hint is to always put your orthogonal concerns (logging, error handling, auditing, etc...) somewhere else and leave your BPEL as clean as possible. For example, with OpenESB (commercially aka JavaCAPS 6) there is a nice JavaEE-SE which is the JBI Service Engine to execute EJBs (practically, it is a JBI bridge to the below application server). Here is a list of all JBI components you can use, have a look at Aspect SE, Camel SE (Apache Camel Service Engine) and Scripting SE for other very interesting opportunities to avoid messing-up your business logic...
Saturday, March 29, 2008
Dynamic Data Models
A recent article on Infoq: Beyond SOA: A New Enterprise Architecture Framework for Dynamic Business Applications gives an interesting point of view about development of Enterprise Applications both from an architecture and a methodology perspective. Article's conclusions are:
"the evolution of flat, stateless, static, client-server web-based solutions have contributed to the disconnect between IT architecture and the real-world of hierarchical, stateful, dynamic, distributed business. We also discussed how traditional engineering approaches do not support the development of adaptive systems capable of supporting the dynamics of business."
A fundamental issue with present enterprise SOA is about the abuse of static data models. As the author explained, relational databases are for static data relationship, but only some parts of the enterprise ecosystem can be considered as being ruled by static relationships. For a more technical example, XML was supposed to be here to overcome relational limitations, as it should provide more robust data representations. In fact, an XML document is robust because by definition you could add elements without breaking the semantic of the document itself, but this is hardly true if then the XML document is parsed into static object wrappers, as most of the "modern" tools provide. As a consequence, proliferation of strict XML schema validation totally eliminates XML intrinsic flexibility and robustness. A more dynamic approach in the manipulation and representation of data flowing in the enterprise should be the focus of next generation softwares. Dynamic data manipulation will provide much better flexibility than static DOM object wrappers that are so common today.
Unfortunately present software tools are still focused on what the author calls static engineering frameworks which are good, even indispensable, to build bridges or airplanes, but very bad to create software useful to represent the dynamic and fuzzy business behavior. The well celebrated web-centric architectural model is good for information representation and retrieval, but when that model is used as a framework to capture and model business real life enterprise applications, then its static nature miserably fails the target.
Basically, a picture of a dog is not a dog, but looks like the software industry still has not fully understood this evidence.
"the evolution of flat, stateless, static, client-server web-based solutions have contributed to the disconnect between IT architecture and the real-world of hierarchical, stateful, dynamic, distributed business. We also discussed how traditional engineering approaches do not support the development of adaptive systems capable of supporting the dynamics of business."
A fundamental issue with present enterprise SOA is about the abuse of static data models. As the author explained, relational databases are for static data relationship, but only some parts of the enterprise ecosystem can be considered as being ruled by static relationships. For a more technical example, XML was supposed to be here to overcome relational limitations, as it should provide more robust data representations. In fact, an XML document is robust because by definition you could add elements without breaking the semantic of the document itself, but this is hardly true if then the XML document is parsed into static object wrappers, as most of the "modern" tools provide. As a consequence, proliferation of strict XML schema validation totally eliminates XML intrinsic flexibility and robustness. A more dynamic approach in the manipulation and representation of data flowing in the enterprise should be the focus of next generation softwares. Dynamic data manipulation will provide much better flexibility than static DOM object wrappers that are so common today.
Unfortunately present software tools are still focused on what the author calls static engineering frameworks which are good, even indispensable, to build bridges or airplanes, but very bad to create software useful to represent the dynamic and fuzzy business behavior. The well celebrated web-centric architectural model is good for information representation and retrieval, but when that model is used as a framework to capture and model business real life enterprise applications, then its static nature miserably fails the target.
Basically, a picture of a dog is not a dog, but looks like the software industry still has not fully understood this evidence.
Friday, February 29, 2008
You Can't Buy SOA Governance
Customers and software vendors have now a brand new keyword: SOA Governance! That is, if you listen to vendors, about the set of practices and (mainly!) products which help the enterprise to manage complex ecosystem of technical and business services, with their related meta-data. You can have a look at this Wikipedia definition for a concise definition of SOA-Governance.
That sounds good, isn't it? But usually when I listen to both customers and software vendors I find their ideas about governance quite misleading. Few points of mine:
1. SOA governance is about a conceptual organizational and operational framework which aims to align IT governance with business analysis procedures: people first, then technicalities.
2. You can't buy SOA, you can't buy SOA Governance. It is an organizational process, if you don't change the way you operate your IT projects you cannot achieve neither SOA nor any governance;
3. You need to build a set of SOA practices together with a governance strategy, and the human factor here is more important than any possible product: there is no magical SOA-in-a-box product.
4. You can't have a SOA without governance, you can't build a SOA governance strategy without an established service-oriented analysis process (because you end having nothing to govern...)
IT is broken: we clearly see this simple and true fact daily, but I hardly find organizations able to recognize the fact that they need to reconcile their IT operations with their business needs first through organizational changes. They too often just try to buy the next magical box and hope that plugging it into their IT department it will fix problems.
Again and as usual: lot of money, few successes and SOA is becoming another abused bad word.
That sounds good, isn't it? But usually when I listen to both customers and software vendors I find their ideas about governance quite misleading. Few points of mine:
1. SOA governance is about a conceptual organizational and operational framework which aims to align IT governance with business analysis procedures: people first, then technicalities.
2. You can't buy SOA, you can't buy SOA Governance. It is an organizational process, if you don't change the way you operate your IT projects you cannot achieve neither SOA nor any governance;
3. You need to build a set of SOA practices together with a governance strategy, and the human factor here is more important than any possible product: there is no magical SOA-in-a-box product.
4. You can't have a SOA without governance, you can't build a SOA governance strategy without an established service-oriented analysis process (because you end having nothing to govern...)
IT is broken: we clearly see this simple and true fact daily, but I hardly find organizations able to recognize the fact that they need to reconcile their IT operations with their business needs first through organizational changes. They too often just try to buy the next magical box and hope that plugging it into their IT department it will fix problems.
Again and as usual: lot of money, few successes and SOA is becoming another abused bad word.
Monday, November 5, 2007
SOA without Technology
In this beautiful article "A Low-Tech Approach to Understanding SOA" Dan North describes a Service-Oriented Architecture in terms of a 1950s corporation, where no computers were available and people worked with just pens, paper and folders.
The idea is to focus attention to the business description level, without mentioning any technology. I think this is a very effective metaphor, which helps shaping the What, Who and Why of a business services architecture without bothering with implementation details.
Forgetting for a while about the technological infrastructure can really improve the quality of description and lead to a cleaner picture of what it is really necessary. SOA is first about People and Process, then Platform (Read this "SOA Methodology" presentation for an example).
There is nothing new under the sun, except that some weird information about SOA has delivered wrong concepts to final customers and it's time for some clarity.
The idea is to focus attention to the business description level, without mentioning any technology. I think this is a very effective metaphor, which helps shaping the What, Who and Why of a business services architecture without bothering with implementation details.
Forgetting for a while about the technological infrastructure can really improve the quality of description and lead to a cleaner picture of what it is really necessary. SOA is first about People and Process, then Platform (Read this "SOA Methodology" presentation for an example).
There is nothing new under the sun, except that some weird information about SOA has delivered wrong concepts to final customers and it's time for some clarity.
Saturday, January 6, 2007
Books: Enterprise SOA Adoption Strategies
Steve Jones, currently a CTO at Capgemini for SOA strategies, wrote this very interesting little book that fills a gap in the IT literature. The term SOA, which stands for Service Oriented Architecture, is a bit of an overused buzzword these days. SOA has to do much more with the business side of an enterprise than with the technological one, while most books focus their attention too much on technical aspects. The target of a SOA strategy, as Steve's book explain very well, is to "deliver IT to the business". This should sound very obvious, shouldn't it? In my experience many technology departments were nowadays being transformed into playgrounds for software programmers and mediocre IT managers instead. A SOA strategy must reinstate IT into its necessary form within the enterprise, which is to be business-driven.
Steve's book explain very well an analysis approach to model a SOA starting from main business functions, down to a decomposition to technical services. The key to a Service Oriented Architecture? As he wrote: "It's the Service, Stupid!". So the second important concept you will understand reading his book is another very often missed point:
SOA must be business-driven and not technology-driven
Steve's book explain very well an analysis approach to model a SOA starting from main business functions, down to a decomposition to technical services. The key to a Service Oriented Architecture? As he wrote: "It's the Service, Stupid!". So the second important concept you will understand reading his book is another very often missed point:
Subscribe to:
Posts (Atom)