tag:blogger.com,1999:blog-61067822024-03-27T10:47:33.315+00:00Architecture, Data and Intelligenceby Richard VeryardRichard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-6106782.post-81994273442272173162014-04-03T09:08:00.000+01:002019-08-22T13:56:10.826+01:00The Enterprise Architect of Hamelyn<br />
<table border="3" cellpadding="3" cellspacing="3"><tbody>
<tr>
<td style="background-color: black; color: white;" valign="top">Stakeholder Concern
</td>
<td style="background-color: black; color: white;" valign="top">Enterprise Focus </td>
<td style="background-color: black; color: white;" valign="top">Project Focus</td>
</tr>
<tr>
<td valign="top">The city of Hamelyn is plagued with rats.
</td>
<td valign="top">This indicates a serious problem with the “Public Health and Hygiene” capability.
</td>
<td valign="top">We just need a quick project to eliminate the rats. So we buy some “Eliminate Creature” capability from an external vendor.
</td>
</tr>
<tr>
<td valign="top">The Pied Piper gets rid of the rats.
</td>
<td valign="top">Real business problem has not been addressed. Let’s now push on with the next phase of solving the problem.</td>
<td valign="top">Project successful.<br />
<br /></td>
</tr>
<tr>
<td valign="top">The Pied Piper is too expensive.</td>
<td valign="top">We need a careful transition plan while we build an in-house capability.</td>
<td valign="top">Let us immediately renegotiate our contract with the vendor.</td>
</tr>
<tr>
<td valign="top">The Pied Piper gets rid of the children.
</td>
<td valign="top">It turns out that the Pied Piper can reuse his “Eliminate Creature” capability for other purposes.</td>
<td valign="top">!*!?**!
</td>
</tr>
<tr>
<td style="background-color: black; color: white;" valign="top">Which Role?
</td>
<td style="background-color: black; color: white;" valign="top">Enterprise Architect?<br />
Strategic Procurement?</td>
<td style="background-color: black; color: white;" valign="top">Solution Architect?<br />
Tactical Procurement?</td>
</tr>
</tbody></table>
<br />
<br />
See also my article “Requirements Engineering as if Stakeholders Mattered” (<a href="http://www.resg.org.uk/wp-content/uploads/2012/11/RQ29.pdf">Requirenautics Quarterly</a><a href="http://www.resg.org.uk/wp-content/uploads/2012/11/RQ29.pdf">, Issue 29, August 2003, pdf</a>)<br />
<br />
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-6106782.post-54525160985220912812012-06-29T11:08:00.000+01:002013-02-01T15:04:40.809+00:00Where were the architects at RBS?<span style="font-size: xx-small;">#entarch </span>Some interesting architectural implications of the recent embarrassing failure of banking systems at RBS-NatWest Bank, which has caused financial stress and distress for millions of customers.<br />
<br />
A banking software expert quoted in the Guardian offered an interesting architectural analogy.<br />
<br />
<blockquote type="cite">
"Banking systems are like a huge game of
Jenga [the tower game played with interlaced blocks of wood]. Two
unrelated transactions might not look related now, but 500,000
transactions from now they might have a huge relation. So
everything needs to be processed in order."</blockquote>
<br />
This analogy suggests that the problem is one of architectural
knowledge and governance. This is always a problem for any large and complex enterprise, but outsourcing typically amplifies such problems. From the press reports, it seems that the implementation
of the RBS-NatWest application architecture has been delegated to a
bunch of relatively inexperienced Indians with little knowledge of the
RBS-NatWest business.<br />
<br />
The finger of blame is being
pointed to CA-7, which I understand to be a middleware product
responsible for the orchestration of complex batch runs. As recently as February, there were job adverts in Inda urgently seeking people with CA-7 experience for the RBS contract. <br />
<blockquote type="cite">
Distributes or centralize job submission,
management and monitoring as you choose and simplify job
management by automating as much as possible and provides a
simple-to-use interface to manage your environment. CA 7® Workload
Automation is a mainframe-hosted, fully-integrated workload
automation engine that coordinates and executes job schedules and
event triggers across the enterprise.</blockquote>
<br />
<a class="moz-txt-link-freetext" href="http://www.ca.com/us/products/detail/ca-7-workload-automation.aspx">http://www.ca.com/us/products/detail/ca-7-workload-automation.aspx</a><br />
<br />
<br />
The Guardian continues<br />
<blockquote type="cite">
It seems whoever made the update to CA-7
managed to delete or corrupt the files which hold the schedule for
the overnight jobs, so they did not run, or ran incorrectly.</blockquote>
<br />
ComputerWorld quotes an RBS spokesman.<br />
<blockquote type="cite">
The focus right now is on fixing the
problem, which was triggered during a software system upgrade.</blockquote>
and BBC's Robert Peston adds<br />
<br />
<blockquote type="cite">
the software update that went so badly wrong last Tuesday night was
fairly quickly identified and patched by Royal Bank; it is the absence
of a contingency plan to deal with the knock-ons from the initial
computer failure that many will see as deeply troubling</blockquote>
<br />
I presume that CA-7 expertise involves the ability to create and
maintain these control files. But these control files essentially
contain executable metadata that describe how the applications must
be joined up, which must ultimately be based on a rigorous view of
the application architecture - in other words, a model of the application layer. <br />
<br />
In my discussion of business capabilities, I have always said that
the most troublesome capabilities (and the ones overlooked by most
business analysts) are the coordination capabilities, and these are
the ones that need the most care when outsourcing. The RBS-NatWest
incident illustrates this point.<br />
<br />
@davidsprott
uses the incident to illustrate the need for application
modernization. But was the problem in the core application systems,
or was it in the platform layer? <br />
<br />
To the extent that application coordination is being managed via
CA-7, it looks suspiciously as if the model of the application layer was embedded in the platform layer, and managed as if it was merely technical infrastructure. This suggests a fundamental architectural flaw in RBS systems - a failure to maintain a clean separation of concerns between the application layer and the platform layer.<br />
<br />
This is one of the reasons why enterprise architecture is important. With clean separation and robust interfaces between the architectural layers (business, application, platform), we can carry out modernization, innovation and continuous change in each layer separately. This follows the principle of pace layering, based on the notion that each layer has a different characteristic rate of change. Without clean separation between layers, the layers shear apart, resulting in misalignment and system failure. And as @<a href="http://twitter.com/davidsprott/status/217539281739186176">davidsprott</a> points out, service enabling has exactly this (layer separation) outcome.
<br />
<br />
Conclusions<br />
<ul>
<li>It's risky outsourcing the core systems unless the architecture is clearly understood and controlled.</li>
<li>Good outsourcing requires a good service architecture, which may include business, app and/or platform services.</li>
<li>Modernization requires good architecture.</li>
<li>In complex systems of systems, coordination is a core business capability. Outsource with extreme caution.</li>
</ul>
<br />
<br />
<hr />
<br />
Charles Arthur, <a href="http://www.guardian.co.uk/technology/2012/jun/25/how-natwest-it-meltdown">How NatWest's IT meltdown developed</a> (Guardian 25 June 2012)<br />
<br />
Anh Nguyen, <a href="http://www.computerworlduk.com/news/it-business/3366112/ca-helps-rbs-resolve-tech-problem-that-led-massive-outage/">CA 'helps' RBS resolve tech problem that led to massive outage</a> (ComputerWorld 25 June 2012)<br />
<br />
Robert Peston, <a href="http://www.bbc.co.uk/news/business-18577109">Is outsourcing the cause of RBS debacle?</a> (BBC News 25 June 2012)<br />
<br />
David Sprott, <a href="http://davidsprottsblog.blogspot.ie/2012/06/rbs-crash-management-prefer-offshoring.html">RBS Crash - Management Prefer Offshoring to Modernization?</a> (25 June 2012)<br />
<br />
See also <a href="http://rvsoapbox.blogspot.co.uk/2012/09/architecture-as-jenga.html" target="_blank">Architecture as Jenga</a> (September 2012)Richard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.com0tag:blogger.com,1999:blog-6106782.post-17307933899722880332011-01-04T23:12:00.001+00:002011-01-04T23:15:22.527+00:00Executives who outsource too much<span style="font-size: xx-small;">#entarch </span>@<a href="https://twitter.com/#%21/Cybersal/status/22404483497594880">Cybersal</a> found a useful article in MIT Sloan Management Review <a href="http://sloanreview.mit.edu/the-magazine/articles/2011/winter/52208/what-happens-when-you-outsource-too-much/">What Happens When You Outsource Too Much?</a> by Francesco Zirpoli and Markus C. Becker (December 2010).<br />
<br />
In my view, the title of the article doesn't do justice to the content. There has been endless discussion on how-much outsourcing. Here is a small selection.<br />
<br />
<blockquote>"Globalization has led corporations to outsource too much of their work and, more important, their intellectual capital. This has created a worldwide level of interdependency that increasingly threatens to disrupt supply lines and markets at times of earthquakes, explosions, terrorist acts, and other disasters in one part of the world." <a href="http://hbswk.hbs.edu/item/5283.html">Has Globalization Reached Its Peak?</a> (James Heskett, HBR, April 2006)<br />
<br />
"Outsourcing is one of the quickest, easiest, and most inexpensive ways to hire help and get things done faster." <a href="http://ezinearticles.com/?Coaching-Women---How-to-Outsource-Tasks-Without-Losing-Control&id=5187954">Coaching Women - How to Outsource Tasks Without Losing Control</a> (Zenobia Garrison, Oct 2010)<br />
<br />
"You don’t want to outsource too much." <a href="http://content.dell.com/us/en/enterprise/d/large-business/disaster-recovery-planning.aspx">Why Outsourcing Can Work</a> (Cormac Foster, Dell, October 2010). </blockquote><br />
According to most of these accounts, the trick is to outsource only those activities that have certain properties.<br />
<br />
<ul><li>"primarily non-strategic activities"</li>
<li>"the tasks that you despise or take up too much of your time"</li>
<li>"don’t fix what isn’t broken"</li>
</ul>To my mind, this is a programme management approach to outsourcing - classifying each business activity separately, and deciding its fate accordingly. In contrast, a truly architectural approach to outsourcing would look at the effect of outsourcing on the relationships between activities, not just on the activities in isolation. This is what I find new and interesting about the Sloan paper; here are some key quotes from it, which may help me to reinforce Sally's recommendation.<br />
<br />
<blockquote>"By 2005, top management realized that pushing outsourcing deep into the product development process had seriously altered the technical heart of the company."<br />
<br />
"There is an important difference between integrating physical systems and integrating the <i>performance</i> of such systems."<br />
<br />
"Managers need to have detailed knowledge and understanding of how subsystems interact within the products to achieve different outcomes. ... Knowledge of underlying components is essential for identifying the consequences of different trade-offs and making the best decisions regarding overall product performance. Component-specific knowledge is key to architectural knowledge."<br />
<br />
"Managing outsourcing by relying on the modularization of the product can have fundamental flaws. Modular product architecture may make good sense for dealing with physical integration, but it is not adequate for resolving issues of performance." <i>(We might say the same about the modularization of the business process.)</i><br />
<br />
"Combining knowledge requires a deep understanding of knowledge, rather than just information scanning or exposure."</blockquote>Richard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.com0tag:blogger.com,1999:blog-6106782.post-88494978210975222632009-03-19T04:34:00.006+00:002019-11-18T13:29:30.317+00:00Tesco outsources core eCommerceIn March 2009, Nick Lansley explained the <a href="http://techfortesco.blogspot.com/2009/03/background-to-tescocom-adopting-atg-e.html">background to Tesco.com adopting ATG e-commerce platform</a>.<br />
<br />
Here are some of the key points.<br />
<br />
1. For years Tesco differentiated itself from the competition by writing its own e-commerce software that fitted in perfectly with its processes.<br />
<br />
2. Competitors who tried to copy this software were unable to replicate its internal functionality. (Nick refers to "special algorithms".)<br />
<br />
3. But the "core systems" are not Tesco's "core business". So Tesco has decided to outsource.<br />
<br />
4. Tesco selected an e-commerce software platform that matches its core systems the closest.<br />
<br />
5. With the core already there, Tesco will devote its IT staff to designing and developing new business improvements and ideas.<br />
<br />
<hr />
<h4>
Analysis</h4>
This story fits with the view of "services on the fault line", which the CBDI Forum adopted and adapted from Geoffrey Moore. Capabilities migrate around the grid. The core e-commerce platform is migrating from top-left to bottom-right; meanwhile Tesco is devoting its internal IT resources to generating new functionality from bottom-left.<br />
<br />
<a href="http://3.bp.blogspot.com/_u-JEi3AfaD0/ScHOZw4sRGI/AAAAAAAAABo/wJwhFfo1T_s/s1600-h/BSPS06.gif" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5314755977288631394" src="https://3.bp.blogspot.com/_u-JEi3AfaD0/ScHOZw4sRGI/AAAAAAAAABo/wJwhFfo1T_s/s320/BSPS06.gif" style="cursor: pointer; height: 209px; width: 320px;" /></a><br />
<br />
The classification of capabilities depends partly on the link to business outcomes / value. It also depends on the knowledge associated with each capability. Correct decoupling between capabilities depends on encapsulating the knowledge (know-how) embedded in each capability. (This is a version of the well-known architectural principle: separation of concerns.)<br />
<br />
So we can understand the strategic cycle of capabilities (core and contextual) proposed by Geoffrey Moore, by reference to a model of the knowledge cycle proposed by Max Boisot.<br />
<br />
<a href="http://2.bp.blogspot.com/_u-JEi3AfaD0/ScHROsWMbZI/AAAAAAAAABw/9n7KleGwFCY/s1600-h/BSPS07.gif" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5314759085626518930" src="https://2.bp.blogspot.com/_u-JEi3AfaD0/ScHROsWMbZI/AAAAAAAAABw/9n7KleGwFCY/s320/BSPS07.gif" style="cursor: pointer; height: 202px; width: 320px;" /></a><br />
<br />
I don't know whether the "special algorithms" remain proprietary to Tesco, or whether they (or at least the "commodity" provided by these algorithms) become available to other users of the same platform. In any case, I guess Tesco will be looking to develop new and more sophisticated algorithms.<br />
<br />
<br />
<hr />
See also<br />
<br />
CBDI Forum, SOA Fundamentals (2009) - <a href="http://tinyurl.com/CBDiForumGeoffreyMoore">key extract from page 222</a><br />
<br />
Richard Veryard and Philip Boxer, <a href="http://msdn.microsoft.com/en-us/library/aa480051.aspx">Metropolis and SOA Governance</a> (Microsoft Architecture Journal 5, July 2005). Philip Boxer and Richard Veryard, <a href="https://msdn.microsoft.com/en-us/library/bb245658.aspx">Taking Governance to the Edge</a> (Microsoft Architecture Journal 6, August 2006)<br />
<br />
Richard Veryard, <a href="http://everware-cbdi.com/public/downloads/pURv0/journal2006-05.pdf">Business Strategy Planning for the Service Economy</a> (CBDI Journal May 2006) <br />
<br />
In his post <a href="https://www.asymmetricleadership.com/2006/04/03/managing-over-the-whole-governance-cycle/">Managing over the whole Governance Cycle</a> (April 2006), Philip Boxer extends the Boisot model to produce a governance cycle appropriate for the platform-based business. See also my post on <a href="https://www.asymmetricleadership.com/2006/04/05/knowledge-and-culture/">Knowledge and Culture</a> (April 2006).<br />
<br />
Related posts: <a href="https://rvsoapbox.blogspot.com/2006/12/service-planning.htm">Service Planning</a> (December 2006), <a href="https://rvsoapbox.blogspot.com/2009/10/ecosystem-soa.html">Ecosystem SOA</a> (October 2009) <a href="https://rvsoapbox.blogspot.com/2010/06/ecosystem-soa-2.html">Ecosystem SOA 2</a> (June 2010)<br />
<br />
<span style="font-size: xx-small;">Updated 13 October 2015. Links updated 18 November 2019</span>Richard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.com3tag:blogger.com,1999:blog-6106782.post-30996523296177543442008-11-19T22:18:00.004+00:002018-06-15T11:46:03.217+01:00Lego Bricks and OutsourcingI've done the one about <a href="http://rvsoapbox.blogspot.com/2008/11/lego-bricks-and-reuse.html">Lego Bricks and Reuse</a>. But did you hear the one about the Lego Company and Outsourcing?<br /><br />Seems the Danes were losing money, so back in 2006 they decided to outsource production to Flextronics, an electronics company in the Czech Republic [<a href="http://www.lego.com/eng/info/default.asp?page=pressdetail&contentid=20727">Lego Press Release, June 2006</a>].<br /><br />Now here's the clever bit. Flextronics would do the plastic moulding, but Lego would retain the manufacture of the electronics.<br /><br />Kevin Meyer is sarcastic. "Sure, why not? Have an electronics manufacturer make the plastics, and a plastics manufacturer keep on making the electronics. That's bound to succeed, right?"<br /><br />The Fast Company wrote a case study about Mass Customization called <a href="http://www.fastcompany.com/magazine/98/dispatch.html">Brick by Brick - Lego's New Building Blocks</a>. And Booz Allen Hamilton wrote a case study called "Rebuilding Lego Brick By Brick", (<a href="http://www.strategy-business.com/">strategy+business</a> August 2007 via <a href="http://chutzpah.typepad.com/slow_movement/2008/09/strategy-business-rebuilding-lego-brick-by-brick.html">Slow Movement</a>).<br /><br />The Booz Allen report had sub-headings like "Approaching the Value Chain Holistically" At that time it looked like the strategy was working.<br /><br />But now Lego and Flextronics have parted company. “It has become increasingly obvious to the two parties that it would be more optimal for the LEGO Group to manage its global manufacturing set up."<br /><br />Kevin Meyer provides an excellent history, and asks <a class="bl_itemtitle" title="Site: Evolving Excellence" href="http://www.evolvingexcellence.com/blog/2008/11/did-lego-learn-a-lesson-did-you.html" target="_blank">Did Lego Learn a Lesson? Did You?</a><br /><br />I read the case as a story of complexity. The product had got more and more complex, and so had the production process. It isn't obvious how an apparently simple outsourcing deal does anything to address this complexity.<br /><br /><hr /><small>By the way, if you search for Lego and complexity, you will also find some wireless network algorithm called Locally Enabled Global Optimization, and a discrete event simulation technique called Listener Event Graph Objects. Presumably these have nothing to do with the Danish toy company. But sometimes people want to reuse a familiar set of initials.<br /></small>Richard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.com0tag:blogger.com,1999:blog-6106782.post-85605462584096029202008-10-17T14:51:00.007+01:002010-02-19T16:00:48.659+00:00Credit Crunch SOA - Outsourcing<i>One of a series of posts exploring how the current economic conditions are affecting the SOA world. What are the implications for organizations and individuals?</i><hr /><h4>Outsourcing</h4>At the level of the individual deal/firm, there are clearly going to be some casualties. Obviously the organizations that are in meltdown, or whose funds are currently frozen in some Icelandic bank account, are not going to be spending money they haven't got and can't borrow. And some emergency take-overs in the banking sector are going to reduce the number of banking systems that need to be built and maintained.<br /><br />But overall, the situation for the outsourcing might not look too bad. Business-as-usual requires systems-as-usual. Indeed, some people in the outsourcing world (for example Phil Morris of EquaTerra via <a href="http://news.zdnet.co.uk/itmanagement/0,1000000308,39489340,00.htm" title="What the credit crunch means for IT (ZDNet 17 Sep 2008)">ZDNet</a>) are arguing that outsourcing is countercyclic - in other words, it goes up when the economy as a whole goes down - because it is cheaper and lower-risk than employing people yourself. (I don't remember anyone saying outsourcing was counter-cyclic when the economy was going up, but I must have missed it.)<br /><br />But what kind of outsourcing is it going to be? Following Archilochus (via <a href="http://www.cc.gatech.edu/people/home/idris/Essays/Hedge_n_Fox.htm">Isaiah Berlin</a> and <a href="http://www.jimcollins.com/lib/goodToGreat/ch5_p90.html">Jim Collins</a>) we can identify two styles of outsourcing: the Fox makes lots of small outsourcing deals and the Hedgehog makes one big outsourcing deal.<br /><br />Som Sarma of Satyam Computer Services is on the side of the Hedgehogs when he writes "As organisations are driven to focus on IT cost having a single supplier can minimise management, due diligence and supplier selection expenses." [<a href="http://www.computerworlduk.com/management/careers-hr/my-career/opinion/index.cfm?articleid=1781">ComputerWorldUK, 2 October 2008</a>] He repeats (in almost identical words) a point made by Martyn Hart back in January who, while acknowledging that the past couple of years has seen a swing away from 'mega deal' towards multi-shoring and choosing separate suppliers for each process, predicted a swing back to the single supplier, arguing that this would provide better cost management. [<a href="http://www.computerworlduk.com/community/blogs/index.cfm?entryid=405&blogid=12&email">ComputerWorldUK, 22 January 2008</a>]<br /><br />However, Som Sarma's colleague Deepak Kataria, speaking at the <a href="http://www.satyam.com/industries/telecom/satyam_sponsers_transforming_oss.asp">New Services Environment Summit</a> in Dallas TX (February 2008), warned against over dependency on single vendor. He recommends defining and implementing a conceptual abstract framework for mapping the technology roadmap to multiple vendor platforms and future versions [see Deepak's presentation on <a href="http://www.satyam.com/industries/telecom/documents/soa_xformation.ppt">SOA Transformation (ppt)</a>].<br /><br />I'm with Deepak on this point. If you have a first-class architecture (and I admit that is a big IF) you can get the best of both worlds - better governance and risk management, as well as better cost management. With SOA, organizations can choose to manage outsourcing at a finer level of granularity, in order to squeeze extra value from the network, as well as keeping closer control over their suppliers. As organizations develop more sophisticated service management capability, they can move from being a simple hedgehog (hand everything over to XYZ Global Services and hope for the best) to being a clever fox.<br /><br />One data point here - reported anxiety at General Motors over the merger between HP and EDS, which means GM is now spending a third of its massive technology budget with a single supplier. [<a href="http://www.channelregister.co.uk/2008/10/17/hp_eds_general_motors_cost_savings/">HP-EDS Combo makes General Motors uncomfortable</a>].<br /><br />Meanwhile, both Som and Martyn identify another critical benefit from outsourcing - a shift towards Pay-As-You-Go models. See my previous post on <a href="http://rvsoapbox.blogspot.com/2008/10/service-oriented-cashflow.html">Service-Oriented CashFlow</a>.Richard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.com0tag:blogger.com,1999:blog-6106782.post-78795678518048867642006-04-17T22:20:00.001+01:002016-01-28T16:24:30.509+00:00Job Bid Market<div class="serendipity_entry_body">
In his latest blog posting, <a href="http://blogs.msdn.com/nickmalik/archive/2006/04/15/576970.aspx">The Service Repository Concept is Incomplete</a>, Nick Malik suggests the creation of an exchange site, onto which service consumers could post a specification of the services they want. Similar demand-led exercises were also proposed for component-based software engineering. I wrote something in the CBDI Journal back in October 2000 about the <a href="http://www.cbdiforum.com/secure/interact/2000-10/job_bid_market.php3">Job Bid Market</a>. More recently (April 2004), <a href="http://www.cbdiforum.com/cbdi_blog/index.php?filter=author&id=2&display=lawrence">Lawrence</a> wrote a <a href="http://www.cbdiforum.com/secure/interact/2004-04/TopCoder-Components_by_Competition.php">review of TopCoder</a>, which has an effective Job Bid Market, and a very precise specification process. <br />
<br /></div>
This is a very attractive idea, for many reasons. However, one of the problems with the Job Bid Market - whether for components or services - is the lack of precision and richness in specification. Without machine-readable precise specifications, the transaction costs are likely to be prohibitive.<br />
Specifications need to include semantics as well as commercial considerations. Some of the characteristics of Web 2.0 may be relevant here, including user-defined semantics.<br />
<br />
Pricing is also interesting. Nick suggests that consumers can indicate how much they would pay. But does this result in everyone using a service paying a different amount - like passengers on an airplane? Or is there some complex auction system where every consumer willing to pay more than X ends up paying the same X? There are some Web 2.0 possibilities here as well.Richard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.com0tag:blogger.com,1999:blog-6106782.post-1126749790644653062005-09-15T03:00:00.000+01:002022-04-06T20:26:04.775+01:00SOA Chaos?<p><a href="http://blogs.zdnet.com/service-oriented/?p=416">Britton Manasco</a> (ZDNet) picks up a story from <span class="byline"><a href="http://www.soa-pipeline.com/shared/article/printablePipelineArticle.jhtml?articleId=170700748">Howard Baldwin</a> (Information Week, via SOA-Pipeline) about an SOA project that ended in chaos. Both writers seem to think the problem comes when you combine SOA with business process outsourcing (BPO). </span></p><p><span class="byline">Howard writes: "</span>The advantage is the disadvantage. You can break business processes down to their most granular, logical elements; focus your development efforts on where you can provide the most differentiation; and let someone else handle the overflow or the low-profit transactions. But you open yourself up to a management challenge the likes of which you've never seen." </p><p>Britton adds: "SOA and BPO (business process outsourcing) aren't a natural match, apparently. Some think the two together can even unleash the forces of chaos." </p><p>But the challenge of SOA has always been a dual one: not just the decomposition of business processes into separate (loosely coupled, reusable and outsourceable) services, but also the composition of these services back into a coherent (integrated) business process. In the project described by Howard, at least in the first iteration, it looks as if lots of effort went into the decomposition, but not enough thought went into the composition. That sounds like a recipe for disaster whether you mix in BPO or not. </p><p>So is BPO irrelevant to this story? Not quite. With BPO it's not so easy to fudge the service-orientation, and the composition failure is more obvious. Perhaps that's not such a bad thing. </p><p>And Howard's story has a happy end. The company was able to to redesign the way messages were handled to ensure that the system-management application only logged the most critical ones. In other words, the service decomposition apparently performed okay once they got the composition right; the solution didn't perform properly at first but could be adapted until it did. Perhaps this is evidence that SOA works after all. </p><p> </p><p>Related posts: <a href="https://rvsoapbox.blogspot.com/2005/09/soa-chaos-2.htm">SOA Chaos 2</a>, <a href="https://rvsoapbox.blogspot.com/2005/09/soa-stupidity.htm">SOA Stupidity</a> <br /></p>Richard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.com0tag:blogger.com,1999:blog-6106782.post-1118917364786059352005-06-16T11:20:00.000+01:002013-03-01T13:30:51.053+00:00SOA Trading BlocsIn his post <a href="http://radovanjanecek.net/blog/archives/000261.html">SOA USA EU</a>, Radovan suggests that the USA is more service-oriented than the EU. He points to the difficulties of interoperability across national, linguistic and cultural boundaries.<br />
<br />
We may note that when services (such as call centres) are outsourced to India, this typically relies on imposing an alien culture and outmoded management practices on the Indian call centre operations, in order to side-step some of these issues. See previous post.<br />
<br />
Let me extend Radovan's speculation as follows. America may have the advantage in moving from phase 1 of SOA to phase 2. But Europe may have the advantage in moving from phase 2 to phase 3. (If anyone has got any evidence either way, please post using the <a href="http://technorati.com/tag/service-oriented" rel="tag">service-oriented</a> tag.)<br />
<br />
<table border="1" cellpadding="2" cellspacing="2" style="text-align: left;"> <tbody>
<tr> <td style="vertical-align: top;">Phase 1</td> <td style="vertical-align: top;">SOA within a single enterprise - vertical (hierarchical) coordination</td> </tr>
<tr> <td style="vertical-align: top;">Phase 2</td> <td style="vertical-align: top;">SOA within a relatively simple homogeneous community - closed network coordination</td> </tr>
<tr> <td style="vertical-align: top;">Phase 3</td> <td style="vertical-align: top;">SOA across a complex heterogeneous landscape - open network coordination</td> </tr>
</tbody> </table>
<br />
This then raises a secondary question: which platform vendors will be best placed to support the move from phase 2 to phase 3, with its complex issues of semantics and trust - American or European ones?<br />
<br />
<small><br /></small>
<a href="http://technorati.com/tag/service-oriented" rel="tag"></a>Richard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.com0tag:blogger.com,1999:blog-6106782.post-1106310752254588062005-01-21T13:21:00.000+00:002008-03-31T14:57:43.849+01:00Software OutsourcingCompanies outsource their software development for several reasons:
<br /> <ol> <li>It is cheaper because the outsource contractors use cheap labour (usually with development shops based in countries with lower wage rates).</li><li>It is cheaper because the outsource contractors can achieve economies of scale - for example through some form of software reuse. (Anyone really believe this?)
<br /> </li><li>It allows companies to manage variations in the volume of software development work, without the need to hire extra staff.</li><li>It reduces the dependence on an inhouse IT department - especially where there is a history of poor performance.
<br /> </li> </ol> But there are some perceived disadvantages of software outsourcing.
<br /> <ol> <li>Increased "distance" and weak communication between the developers and the users. Issues of business/IT alignment.
<br /> </li><li>Reduced client control over the software product and process. Issues of trust and security.
<br /> </li> </ol> In this post, I want to discuss how a service-oriented approach affects this equation.
<br />
<br /> <h4>Architecture</h4> The customer organization typically retains responsibility for requirements and architecture. This means that the software specifications are produced by business analysts and software architects in the customer organization. The outsource contractor then produces software artefacts according to these specifications and delivers these artefacts back to the customer organization, where they are tested and deployed.
<br />
<br /> The first problem here is with the depth of the testing. Most IT departments have got people who know how to do functional testing, usability testing, performance testing - but that's not enough. Presumably the architects have devoted some attention to producing an overall solution with certain architectural characteristics, such as flexibility/maintainability. The requirements will have been stratified into layers and decomposed into discrete units (modules, components, services); the architects will have sought to achieve high cohesion and low coupling, both horizontally and vertically.
<br />
<br /> However, developers may have an incentive to produce software that is inflexible and more expensive to maintain, because this generates future income for themselves. They can achieve this by introducing hidden coupling between layers, tight coupling where the architects intended loose coupling, inappropriate bindings of varying kinds. Even if these are detected, it is hard to determine whether they were inserted deliberately or merely slipped in as a result of poor development practices. And in most cases, they will not be detected until much later.
<br />
<br /> So it is crucial for architects in the customer organization to verify that the developers have conformed to the original architectural intentions. This entails an ability to discover the actual architectural structure of the delivered software artefacts - and this may involve a combination of code inspection (static analysis) and runtime monitoring (dynamic analysis). We are starting to see web service modelling and management tools that provide some support for <span style="font-weight: bold;">architecture discovery</span>; the next step will be tool support for <span style="font-weight: bold;">architecture verification</span>.
<br /> <h4>Automation</h4> Service-oriented computing reinforces the importance of tools. In the past, development tools for modelling, design and code-generation were regarded as productivity aids. This meant they were sometimes used in high-wage economies (USA, Western Europe) to cut labour costs, but could not be cost-justified in lower-wage economies (Eastern Europe, India).
<br />
<br /> One modelling tool vendor tells me that this is now changing, at least in India (but not yet in Eastern Europe/Russia), where software companies acquire these tools to improve the relationship with the client and to improve software quality. In other words, the relationship between the outsourcing customer and the outsourcing provider is being automated - reducing the communication distance between developers and users.
<br /> <h4>Agility/Granularity</h4> The growing importance of components and services opens up the possibility of software development at a much finer level of granularity, with small software artefacts developed independently and composed using web service protocols and orchestration languages (such as BPEL).
<br />
<br /> Although this could result in a degree of fragmentation, we may expect collaborative software development platforms to appear, which would have to deal with the administration, transaction costs and requirements/quality issues - probably with a strong flavour of agile development
<br /> <h4>Anticlockwise
<br /></h4> In terms of the <a href="http://www.veryard.com/notions/2005/01/collaborative-composition.htm">Boxer Model of Collaborative Composition</a>, software outsourcing typically follows an anticlockwise path - focused on achieving economies of scale. There are significant challenges involved in moving to a clockwise path. I shall return to this subject in another post.
<br />
<br />Richard Veryardhttp://www.blogger.com/profile/04499123397533975655noreply@blogger.com0