My friendly Software AG representative recently gave me a copy of the "BPM Basics for Dummies". This was an interesting little book pitched at the Executive level. It would not help an IT person to get started with any particular product set but would help them understand what all the fuss was about.
BPM (see note below) has been with us since at least the 1980s. It used to a paper process of writing up the process and then getting a team of programmers to build it, then implementing it on usually a big computer that could handle it and then have the computer operators monitoring it.
In the 1990s Business Process Reengineering (BPR) was an approach which changed an organizational process. It involved process diagrams, IT change and business change.
The excitement with BPM is that some of the leg work involved in actually building systems can be removed if the components of the business process are already established. In this case the components are Web Services enabled through an SOA.
What interests me about this is that some of the concepts behind BPM are a lot easier to explain to the business than SOA. You can get out the Lego blocks and explain the benefits of agility until you are blue in the face but you are still only talking in analogies and expecting the business to take a leap of faith. If you show the business a diagram of one of their business processes and then tell the business the cost of changing that business process then that makes sense in terms the business understands. Of course there is a significant investment in infrastructure, tools and services to establish before you get to that point. It is this significant investment that the IT executive wants to sell. If you are pushing a plan to buy infrastructure, tools and establish services then the plan will make more business sense if the objective is BPM rather than SOA.
I think Software AG understands this and that is why they are giving out "BPM Basics for Dummies" and not "SOA Basics for Dummies". I think the business will get behind BPM before they will embrace SOA. We may see more push for BPM to business executives and SOA may take a back seat. The IT department however knows it needs SOA to get BPM to work. That is just how it meets the business goal of BPM.
Note:
BPM stands for Business Process Management, but you would excused for thinking it stood for Business Process Modeling. The "Management" implies that we are doing a lot more than mapping out the processes. The "Management" moves beyond documenting the processes to making them happen and monitoring their effectiveness.
This is not to be confused with BPMN (Business Process Modeling Notation) where the "M" stands for "Modeling". BPMN however can move beyond an aesthetic model to an operational system by converting it to BPEL.
References:
http://www.ebizq.net/hot_topics/bpm/
http://www.bpmn.org/Documents/Mapping%20BPMN%20to%20BPEL%20Example.pdf
http://en.wikipedia.org/wiki/Business_process_reengineering
Kiran Garimella, Michael Lees and Bruce Williams, "BPM Basics for Dummies (Software AG Special Edition)", Wiley Publishing Inc. 2008.
Showing posts with label Lego. Show all posts
Showing posts with label Lego. Show all posts
Sunday, August 3, 2008
Saturday, April 26, 2008
Lego, Carrots and Coleslaw
I discovered Jeff Schneider's blog archive about SOA and Lego blocks. He has added some great photos. Unlike some other photos illustrating SOA on the web these blocks on the photo are real lego. Jeff discusses accessibility, recombination, composite applications and peer-oriented systems using the metaphor of lego blocks. He also makes judicial used of carrots, cabbage and coleslaw.
I have discussed some of the advantages and disadvantages of the lego metaphor in my earlier posting Lego and SOA. It has also made an appearance in some videos I have seen and conferences I have attended.
I have discussed some of the advantages and disadvantages of the lego metaphor in my earlier posting Lego and SOA. It has also made an appearance in some videos I have seen and conferences I have attended.
Friday, October 5, 2007
Conference Summary Served with Spaghetti
I presented at a conference “Achieving Interoperability in Systems Architecture” on Wednesday. The occasional get together of architects, managers and developers is valuable. You can grab the odd new insight and find new approaches but it is also good to see others attacking problems in the same way and validating your own approaches.
After the conference I thought I would finish this summary on the aeroplane home. I have always wondered how to spend the time on long flights profitably and I admired a couple of passengers using laptops on my previous flight. Unfortunately as I try to use the laptop in flight I am in a middle seat with no elbow room on either side, and now I am served dinner in middle of the flight. I am juggling my laptop and the worst Spaghetti Bolognaise I have ever tasted. Still, here is the summary.
Josh Graham of Thoughtworks kept time well and came up with the comment “Why should I expect straight lines on my Business Process Model when business is inherently messy.” He also introduced one of our New Zealand guests as coming from the land of the “Wrong White Crowd” which sounds like a political comment and spoonerism wrapped up into one.
Mark Murphy of Tower Aust Ltd advocated we start small with SOA. He quoted IDC showing growth in SOA from $3.5bn in 2005 to $33bn estimated in 2010. Mark looked at some SOA definitions and aptly described the current situation where people build silo applications and then expect IT to join them together. He showed a couple of models from Sun and Microsoft showing SOA models that illustrated logical SOA.
Stephen Smith of Arcbok presented a simple framework for assessing the readiness of an organization for SOA. The framework consisted of assessing an organization on the dimensions of Leadership & Culture, Business, Technology, Knowledge, Funding and Sustainability. Each dimension has a number of questions to ask about an organization to asses its readiness. The sustainability dimension described whether the organization had the appropriate support, operations and governance in place for sustain the SOA. This also could include appropriate operational monitoring, measuring and standards. A readiness assessment tool is about risk management. Beware vendor maturity assessments that are used as tools to sell more services.
Krist Davood of AGL and Sensis has achieved something that everyone in the room envied. He had success justified SOA as an initiative using fairly hard-nosed accounting principles. He had justified SOA because of its ability to avoid periodic failures in the business because of the current way of doing things. He had been able cost these failures and justify the project to introduce SOA into the organization. SOA as a strategy to eliminate risk had been demonstrated to be effective.
Centrelink is a huge SOA operation and it was good to hear from Rob Doughty who is their Applications Architect. I liked his characterization of users as “Human Task Delegates” in relation to workflow applications. It was interesting for me to hear about the legacy system challenges that Centrelink have, but also how their portal work in benefiting other government departments. The focus of the talk was the deployment of a portal product which they will be basing all their systems on. I liked the comment that “Portals bring people and process together”. Rob talked about the challenge of working with various IT groups to deliver on a particular pattern of use in relation to the portal. He advocated the use of an “Integration Competency Centre”.
I then presented on Enterprise Architecture and its links to metadata and SOA. Some of this material is already on my posting on SOA Definitions, SOA Metadata and the Zachman Framework. I will elaborate in a future posting.
John Fisher from the NZ Ministry of Education showed us some great business modelling techniques that had found favour with his users. The technique involved Business Element Models, Business Component Models, Business Role Responsibilities and Business Service Models. The models were focussed on producing requirements for widely federated (eg. For 2,700 schools) SOA systems. He introduced the analogy of using power adapter so could use a drill brought in the UK to explain SOA to users.
Jan McConchie of SA Government ICT Services provided an overview of the challenges that she has to bring together the South Australian Government Services to present a common face to the South Australian citizen. This was interesting because the SA Government has established and Office of the CIO and this is showing the desire to coordinate and rationalise government IT activities. As one of the agencies involved, my organisation will be affected by standardisation and IT governance changes. Jan drew on research by Gartner and Saugutuck Technology to explain what SOA meant to her and discussed some initiatives in place for the SA Government.
Chris Howard was from the State Revenue Office of Victoria. Chris focused on risk and SOA and quoted Gartner, advising that it would take 3-4 years before investments in SOA payed off. He discussed a long term plan for legacy transition which was underpinned by full and frank statements about costs, benefits and risks with his business. Chris endorsed ITIL as an enabler of SOA.
Josh ran an interactive session where we discussed the issues of SOA and getting the business on board. It was never clear what you will find when you "turn over rocks" in the analysis process. We discussed what services to build first. It was not always best to do the low risk, high value project first. In the end it might just be business or legislative imperatives that help you make the decision. It was difficult to decide when to do those cross-cutting "hygiene" services.
George Cascales from Integral Energy discussed how he was implementing SOA in an out-sourced environment. He had a small group of architects and had succeeded in being able to develop new applications quickly using reused services. His group focused on standards and governance rather than the actual development. A set of tools and standards would be given to contract developers to develop the services and applications.
Rajat Chopra, the international speaker from Bell Canada provided a good description of how Bell embraced SOA. It was important for Bell to provide common services to serve its various customer channels for selling telecommunication facilities. Rajat provided us with a number of analogies for explaining SOA to management including Lego blocks, a car factory and diet. With diets, you can latch onto gimmicks but in the end it is lifestyle change that makes the difference. This is the same with SOA.
Alex Jouravlev representing the ACS presented twice. Alex’s first presentation was titled Prepare IT and Business for SOA. He traces the origins of SOA back to 1988. He made the point that our business cases do not really engage the business and we need to strive for simple messages using language the business understands to achieve a ‘mental ownership’. Alex supported the model driven architecture approaches but not for the reasons that they were developed. Business requirements should be developed with referencing any ‘system’ and should be modelled with Visual UML Models. Alex noted that several modelling practices that were usually acknowledged as important were often missed. These include Conceptual Business Modelling, Conceptual Data Modelling, Business Object Modelling and producing an Enterprise Ontology.
Later in the day Alex was able to present a model based on CMMI maturity model in an easy-to-understand fashion with the purpose of moving the SOA objective from IT to the business as an organisation obtains more SOA maturity. Alex was able to give us a realistic view of the limitations that would be expected at each level of maturity and provide an insight into how the role of key players like the Enterprise Architect and Business Analyst would change at the various levels.
Ram Kumar was from OASIS and provided an insight into the work of this organisation that is emersed in creating SOA standards. He discussed his role in developing the Justice Sector Information Interchange standard. This was of special interest to me because of my involvement in this sector. Ram emphasised the importance of XML governance and advocated this for successful SOA.
Josh summarised the conference and he may discuss this on his own blog site. Many themes resonated with me but one stands out as I wrestle with my in-flight dinner. We had slides from at least three of the speakers that showed insanely complicated maps of their existing systems. It seems we are all lumbered with integration spaghetti and our hope is that SOA will resolve this.
After the conference I thought I would finish this summary on the aeroplane home. I have always wondered how to spend the time on long flights profitably and I admired a couple of passengers using laptops on my previous flight. Unfortunately as I try to use the laptop in flight I am in a middle seat with no elbow room on either side, and now I am served dinner in middle of the flight. I am juggling my laptop and the worst Spaghetti Bolognaise I have ever tasted. Still, here is the summary.
Josh Graham of Thoughtworks kept time well and came up with the comment “Why should I expect straight lines on my Business Process Model when business is inherently messy.” He also introduced one of our New Zealand guests as coming from the land of the “Wrong White Crowd” which sounds like a political comment and spoonerism wrapped up into one.
Mark Murphy of Tower Aust Ltd advocated we start small with SOA. He quoted IDC showing growth in SOA from $3.5bn in 2005 to $33bn estimated in 2010. Mark looked at some SOA definitions and aptly described the current situation where people build silo applications and then expect IT to join them together. He showed a couple of models from Sun and Microsoft showing SOA models that illustrated logical SOA.
Stephen Smith of Arcbok presented a simple framework for assessing the readiness of an organization for SOA. The framework consisted of assessing an organization on the dimensions of Leadership & Culture, Business, Technology, Knowledge, Funding and Sustainability. Each dimension has a number of questions to ask about an organization to asses its readiness. The sustainability dimension described whether the organization had the appropriate support, operations and governance in place for sustain the SOA. This also could include appropriate operational monitoring, measuring and standards. A readiness assessment tool is about risk management. Beware vendor maturity assessments that are used as tools to sell more services.
Krist Davood of AGL and Sensis has achieved something that everyone in the room envied. He had success justified SOA as an initiative using fairly hard-nosed accounting principles. He had justified SOA because of its ability to avoid periodic failures in the business because of the current way of doing things. He had been able cost these failures and justify the project to introduce SOA into the organization. SOA as a strategy to eliminate risk had been demonstrated to be effective.
Centrelink is a huge SOA operation and it was good to hear from Rob Doughty who is their Applications Architect. I liked his characterization of users as “Human Task Delegates” in relation to workflow applications. It was interesting for me to hear about the legacy system challenges that Centrelink have, but also how their portal work in benefiting other government departments. The focus of the talk was the deployment of a portal product which they will be basing all their systems on. I liked the comment that “Portals bring people and process together”. Rob talked about the challenge of working with various IT groups to deliver on a particular pattern of use in relation to the portal. He advocated the use of an “Integration Competency Centre”.
I then presented on Enterprise Architecture and its links to metadata and SOA. Some of this material is already on my posting on SOA Definitions, SOA Metadata and the Zachman Framework. I will elaborate in a future posting.
John Fisher from the NZ Ministry of Education showed us some great business modelling techniques that had found favour with his users. The technique involved Business Element Models, Business Component Models, Business Role Responsibilities and Business Service Models. The models were focussed on producing requirements for widely federated (eg. For 2,700 schools) SOA systems. He introduced the analogy of using power adapter so could use a drill brought in the UK to explain SOA to users.
Jan McConchie of SA Government ICT Services provided an overview of the challenges that she has to bring together the South Australian Government Services to present a common face to the South Australian citizen. This was interesting because the SA Government has established and Office of the CIO and this is showing the desire to coordinate and rationalise government IT activities. As one of the agencies involved, my organisation will be affected by standardisation and IT governance changes. Jan drew on research by Gartner and Saugutuck Technology to explain what SOA meant to her and discussed some initiatives in place for the SA Government.
Chris Howard was from the State Revenue Office of Victoria. Chris focused on risk and SOA and quoted Gartner, advising that it would take 3-4 years before investments in SOA payed off. He discussed a long term plan for legacy transition which was underpinned by full and frank statements about costs, benefits and risks with his business. Chris endorsed ITIL as an enabler of SOA.
Josh ran an interactive session where we discussed the issues of SOA and getting the business on board. It was never clear what you will find when you "turn over rocks" in the analysis process. We discussed what services to build first. It was not always best to do the low risk, high value project first. In the end it might just be business or legislative imperatives that help you make the decision. It was difficult to decide when to do those cross-cutting "hygiene" services.
George Cascales from Integral Energy discussed how he was implementing SOA in an out-sourced environment. He had a small group of architects and had succeeded in being able to develop new applications quickly using reused services. His group focused on standards and governance rather than the actual development. A set of tools and standards would be given to contract developers to develop the services and applications.
Rajat Chopra, the international speaker from Bell Canada provided a good description of how Bell embraced SOA. It was important for Bell to provide common services to serve its various customer channels for selling telecommunication facilities. Rajat provided us with a number of analogies for explaining SOA to management including Lego blocks, a car factory and diet. With diets, you can latch onto gimmicks but in the end it is lifestyle change that makes the difference. This is the same with SOA.
Alex Jouravlev representing the ACS presented twice. Alex’s first presentation was titled Prepare IT and Business for SOA. He traces the origins of SOA back to 1988. He made the point that our business cases do not really engage the business and we need to strive for simple messages using language the business understands to achieve a ‘mental ownership’. Alex supported the model driven architecture approaches but not for the reasons that they were developed. Business requirements should be developed with referencing any ‘system’ and should be modelled with Visual UML Models. Alex noted that several modelling practices that were usually acknowledged as important were often missed. These include Conceptual Business Modelling, Conceptual Data Modelling, Business Object Modelling and producing an Enterprise Ontology.
Later in the day Alex was able to present a model based on CMMI maturity model in an easy-to-understand fashion with the purpose of moving the SOA objective from IT to the business as an organisation obtains more SOA maturity. Alex was able to give us a realistic view of the limitations that would be expected at each level of maturity and provide an insight into how the role of key players like the Enterprise Architect and Business Analyst would change at the various levels.
Ram Kumar was from OASIS and provided an insight into the work of this organisation that is emersed in creating SOA standards. He discussed his role in developing the Justice Sector Information Interchange standard. This was of special interest to me because of my involvement in this sector. Ram emphasised the importance of XML governance and advocated this for successful SOA.
Josh summarised the conference and he may discuss this on his own blog site. Many themes resonated with me but one stands out as I wrestle with my in-flight dinner. We had slides from at least three of the speakers that showed insanely complicated maps of their existing systems. It seems we are all lumbered with integration spaghetti and our hope is that SOA will resolve this.
Friday, September 28, 2007
SOA Videos
I read a posting by Collin Smith which included some YouTube videos. This gave me the idea to do my own posting on SOA videos. This also gives me the opportunity to reuse my keywords 'Monkeys' and 'Lego' which so far I have only used once each. My most popular posting so far has been 'Chasers War on Wikipedia' which is more about entertainment than SOA. This posting may be similar.
First, here are some YouTube videos. They have obviously all come from the same source but I am not sure who takes the credit for these.
SOA is like Lego Blocks, http://www.youtube.com/watch?v=sbd_1G8Kqjs&eurl=http%3A%2F%2F
I have a previous posting on this analogy. Like other commentators for some reason they have not used real Lego blocks in the video. Instead they have used a pale imitation. At least they have called them 'Building Blocks' rather than 'Lego'.
SOA is like Music, http://www.youtube.com/watch?v=zV860odGN5Y
This fits with discussion on SOA orchestration but still does not do a lot for me.
SOA is like choosing what wear, http://www.youtube.com/watch?v=dyHWAiG6c-Y
This analogy took me by surprise and it does not really work for me, but the girl is pretty.
Greg the Architect, http://www.gregthearchitect.com/index.html
If you have not seen 'Greg the Architect' yet, then you are missing out. This is the pinnacle of SOA satire, even if it is the pinnacle of a very low heap. It is produced by the people at http://www.soanowjournal.com/. At the time of writing there are four episodes.
First, here are some YouTube videos. They have obviously all come from the same source but I am not sure who takes the credit for these.
SOA is like Lego Blocks, http://www.youtube.com/watch?v=sbd_1G8Kqjs&eurl=http%3A%2F%2F
I have a previous posting on this analogy. Like other commentators for some reason they have not used real Lego blocks in the video. Instead they have used a pale imitation. At least they have called them 'Building Blocks' rather than 'Lego'.
SOA is like Music, http://www.youtube.com/watch?v=zV860odGN5Y
This fits with discussion on SOA orchestration but still does not do a lot for me.
SOA is like choosing what wear, http://www.youtube.com/watch?v=dyHWAiG6c-Y
This analogy took me by surprise and it does not really work for me, but the girl is pretty.
Greg the Architect, http://www.gregthearchitect.com/index.html
If you have not seen 'Greg the Architect' yet, then you are missing out. This is the pinnacle of SOA satire, even if it is the pinnacle of a very low heap. It is produced by the people at http://www.soanowjournal.com/. At the time of writing there are four episodes.
- Greg the Architect SOA
- Greg the Architect ROI
- Greg the Architect Focus Pocus
- Greg the Architect - Off the Grid
SOA Monkey, http://www.youtube.com/watch?v=cM31qu9T3Iw
This one appealed to me. It is seriously off the wall. This monkey knows a bit about SOA though.
The following videos are more informative than entertaining.
There are some good interviews with SOA people of note at http://tv.sys-con.com/read/category/1260.htm . These interviews have advertisements though. I liked one I found on YouTube with the advertising removed 'SOA Power Panel with Jeremy Geelan'. There were a couple of good things I got out of this hour long video. Firstly the quote "Think different. Don't think too long" and secondly eight service characteristics of SOA:
- Loose-Coupling
- Contracts
- Manageability
- Versioned
- Discoverable
- Addressable
- Distributed
- Point to Point (None of the speakers seemed to agree with this one)
- Self-Describing (This was a ninth one that was added by a speaker)
Tarrant County implements SOA for criminal justice agencies, http://www.youtube.com/watch?v=JIpLllGl1fc
This is advertising for Progress Software but I liked it because I work for a justice agency.
SOA - Service Oriented Architecture Introduction, http://www.youtube.com/watch?v=sRFwswaJpD0
This was a good SOA definition but turn down the sound because the speaker sounds like she is reading a children's story.
Another good source of SOA video is http://www.infoq.com/. I have mentioned these in earlier postings. In the posting 'ESB or not ESB?' I referenced some videos from Mark Richards (http://www.infoq.com/presentations/Enterprise-Service-Bus) and Sandy Carter (http://www.infoq.com/interviews/sandy-carter-soa). In 'AOP: The worst form of Coupling' I use Jim Webber's comments about MEST from http://www.infoq.com/news/2007/08/jim-webber-interview.
Sometimes after a hard day at the office reading pages of IT jargon I find the videos easier to absorb than more text information. I hope you can find something here that is either entertaining or informative.
Wednesday, July 11, 2007
Lego and SOA
Lego has been used many times as a metaphor for SOA. I first came across it during a vendor presentation and was not particularly impressed by it as I immediately saw some shortcomings in the metaphor.
After thinking about how I would explain some of the benefits of SOA like agility and loose coupling I decided Lego might be fairly descriptive after all. I ended up doing my own presentation on SOA at a planning session complete with blocks from my kids' Lego set. I felt this was one of my more entertaining presentations and it helped get across some good messages. I plan to post a transcription of the presentation on this blog. As it was a "show and tell" presentation I need to get my digital camera fixed first.
When I did this talk I did not realise the Lego metaphor for SOA was so common. Google brings up many hits that relate the two. It is sometimes handy in IT to show something tangible to explain our concepts. What we build is never clearly visible and how we build it is often very abstract.
Gian Trotta does a good job of looking at this metaphor.
These components are loosely coupled code components that represent well-defined and self-contained business services. “This is important. Loose coupling is a design criterion that enables agility. It can't depend on the context or state of other services,” she noted.The business services become part the overall service oriented architecture (SOA). “Service-oriented architectures require well-defined interfaces and this is the evolving role of Web services. Finally, we have a standard interface that everyone's agreed on, enabling service-oriented architectures to take off,” Gold-Bernstein added.
I do not think much of the Swiss army knife metaphor though. For me SOA is not a grab bag of utilities that can be applied to any problem.
Jason Bloomberg was the source of the above illustration (which is not actually Lego, see footnote) but covers the whole Lego issue pretty well.
As with any analogy, the parallels only go so far, but with Lego blocks, we've found four positive salient characteristics -- and four negative ones
Some of Jason's points identify problems with Lego rather than problems with Lego as a metaphor for SOA. He raises the issue that Lego blocks are so unbreakable that they get passed down the generations so new generations do not buy enough new blocks. This is why the new Lego has so many different parts and looks more realistic. The Lego company is trying to get kids to build it and put it on display rather than reuse it. I see this as a strength of the Lego metaphor (or 'analogy' as Jason refers to it). This is excellent reuse but it also shows the importance of overall architecture. The architecture has adapted to meet the purposes of the business.
The physical nature of Lego means that structures are easier to break as they get bigger, composed of more building blocks. It is interesting to speculate on whether this is true for SOA. Will a big SOA implementation become more fragile? My feeling is that with good design and testing it could be fairly robust but in practice any system with more components and connections will have more points of failure.
Jason states "Lego blocks are interoperable with each other, but not with other kinds of toys." He has a very good point here. Adapters can be built for Lego. I used some sticky tape and a bit of wire attached to Lego blocks when I was demonstrating legacy adapters for an SOA. It is not common practice though to interface Lego with other toys.
Jason's last negative characteristic is "Lego blocks are for children, but children couldn't build Legoland". All metaphors have to break down at some time. SOA is not for children. Services are not made of plastic or cannot fit in an ice cream container either. The metaphorical point is that services can be composed together in an ad hoc fashion without much forethought, but to build large systems with many services that meet the needs of the business requires good SOA and discipline.
One failure of the metaphor I do think has merit is from Jack van Hoof who observes
First start building a nice fortress with LEGO blocks. Then after you finished it, just change one little LEGO block somewhere in the middle of the wall. You won't be very happy, I suppose. Not to mention creating a new window or a door. ... LEGO constructs are easy to be build, but a nightmare to be changed ...
The concern I originally had with the Lego metaphor is aptly covered by a quote from an article by Joe McKendrick who in turn is quoting a vendor white paper
But unlike a single LEGO block, which can only be used in one design at a time, a 'service' can be used by several applications at once (much like a letter in a crossword puzzle).
It is an advantage of software that it can used to process many business processes and it does not get consumed in the process. I sometimes like to consider the service is the block design rather than the actual block but I would not want to try to explain this to an audience as the metaphor starts to lose its simplicity.
The Lego metaphor has been used before in IT and will probably be used for other engineering disciplines. It is a popular model for describing why one might want to build things in parts, why we use standards and how we make big, complex systems out of simple building blocks. For me, Lego continues to be descriptive for SOA. Any discussion about its strengths or weaknesses as a metaphor just seem to help explain more concepts about SOA.
Footnote:
The image above has been presented in a number of articles by Jason Bloomberg of Zapthink. Please note that the blocks illustrated here are not standard Lego blocks. This is a photo of some other interconnecting toy. Standard Lego blocks have the Lego trademark on each of the bumps. Standard Lego blocks also have a gap between the bumps which is larger than the radius of the bumps.
References
- Totta, Gian, The Lego/Swiss Army Knife Approach to SOAs http://www.ebizq.net/topics/soa/features/4040.html
- Bloomberg, Jason, The Lego® Model of SOA, http://www.zapthink.com/report.html?id=zapflash-20061212
- Van Hoof, Jack, SOA and LEGO, do you dare to compare?, http://soa-eda.blogspot.com/2006/12/soa-and-lego-do-you-dare-to-compare.html
- Taylor, James, If SOA is Lego then decision services are Mindstorms http://www.ebizq.net/blogs/decision_management/2006/12/if_soa_is_lego_then_decision_s.php
- McKendrick, Joe, Why are we building ‘enterprise’ SOAs with ‘LEGO blocks’?http://blogs.zdnet.com/service-oriented/?p=777
LEGO® is a trademark of the LEGO Group of companies which does not sponsor, authorize or endorse this content.
Subscribe to:
Posts (Atom)
