+1
I'd add that often IT deploys technical things _thinking_ they are
functional because the vendors have convinced them that they are.
Steve
2009/10/7 Gregg Wonderly <[email protected] <mailto:[email protected]>>
I think that in the end, it's that business has no idea about what it
"technically" needs, but does have all the knowledge about what it
"functionally" needs. Because business doesn't know how to take it's
functionally requirements and express them as things that
"technically" need to
happen, IT is always buying and deploying stuff that it
"technically" sees
solving problems, but doesn't know how to "functionally" make them
useful.
Gregg Wonderly
Michael Poulin wrote:
> I agree with Steve. I have read a couple of researches that
state that
> IT adopts changes 3 times (in average) slower than Business.
Plus, IT's
> 'supporter' role does not help in acceleration. IT will be
moving faster
> only if it is a part of the business.
>
> Actually, Business Architecture has as much to do with PaaS as SO
> architecture has to do with Web Service technology. There is no
and will
> be no business orientation in the IT until Business finally
understands
> that it is service-oriented at the top and must preserve this
for the
> rest of the business structure, and, BTW, picks up IT for
automation of
> some business service functionality. Will IT use WOA, BPLM,
Assembler -
> does not matter whilst the business service runs and capable of
adopting
> changes at the pace of their appearance.
>
> I think that only shared calculation power and storage resources
may be
> left in separated IT, everything else, including shared technical
> services, should be embedded into the business structure with
direct
> business accountability. Shared technical services may belong to
the
> cross-functional cross-divisional management, all others - to
the domain
> LOB/BU. At the same time, the authority of the cross-functional
> cross-divisional management must be equal or higher than the
authority
> of divisional management (EA including Business and Technical
enterprise
> architects has also to report to cross-functional cross-divisional
> management). I describe this model in 'Ladder to SOE'.
>
> - Michael
> ----------------------------------------------------------
> *From:* Steve Jones <[email protected]
<mailto:jones.steveg%40gmail.com>>
> *To:* service-orientated-architecture
> <[email protected]
<mailto:service-orientated-architecture%40yahoogroups.com>>
> *Sent:* Tue, October 6, 2009 2:32:22 PM
> *Subject:* Re: [service-orientated-architecture] Hinchcliffe on
SOA's
> Direction
>
>
>
> This reads like a "WOA as a Silver Bullet" post. The first point is
> where I take issue and its followed up with the chart as to what
> "business" is. The reason why the business is evolving faster is
that
> fundamentally IT isn't organised around the business its organised
> around EA and Software. Putting Business Architecture and PaaS
at the
> same level of "business orientation" is just nonsense but its
the sort
> of nonsense that is all pervading in the industry.
>
> What makes SOA work is reorganising your IT department BASED on
those
> services and making people ACCOUNTABLE to the business for the
delivery
> of the business services. Whether you use WOA, WS-*, BPEL, COBOL or
> what ever is irrelevant as it will be dictated by the particular
> constraints that you have in a given area. A thin veneer of REST
is NOT
> going to solve all these problems and magically make all of the
systems
> inside and outside of an organisation turn into easy to consume
building
> blocks.
>
> SOAP didn't do that, REST won't do that. What will make the
change is
> re-orientating IT towards the business and away from technology.
>
> Steve
>
>
> 2009/10/6 Gervas Douglas <gervas.douglas@ gmail.com
<http://gmail.com>
> <mailto:[email protected]
<mailto:gervas.douglas%40gmail.com>>>
>
>
>
> <<I've been spending the year assessing where enterprise
> architecture -- and SOA in particular -- are headed as we begin to
> leave the first decade of the 21st century. The good news: It's
> clear that EA and SOA are delivering real value to most businesses
> today. However as we'll see, there is also considerable room for
> performance improvement. Trying to map out the direction of these
> disciplines has resulted in quite a snapshot
>
<http://www.slideshare.net/dhinchcliffe/transforming-software-architecture-bouvet-2009>
> with many interesting details and nuances that I'll share here
> throughout the rest of the year.
>
> More immediately of interest we can see some trends beginning to
> stand out clearly right now:
>
> 1) *Modern software architecture, with SOA as the top-level
> organizing principle, seems to have more and more trouble keeping up
> with the /rate of change/ in most organizations.* Not only have the
> timelines and schedules of IT and architecture groups never aligned
> well with business activities, it's now becoming an endemic problem
> as I've shared experiences with architects around the world
> recently. There's a growing sense that the business is "pulling
> away" and despite enterprise architecture and SOA being
> intentionally proactive, the default stance is one of short-term
> reactive response and trying to "clean up afterward", an activity
> which few businesses want to pay for. In short, our traditional
> services delivery models seem to move too slowly these days to
> embrace business opportunities as they occur.
>
> 2. */Consumption/ of SOA and service-based IT is still too low.*
> Depressingly low in some cases. The early "field of dreams" approach
> to services that some organizations practiced (build them and they
> will come) combined with the proliferation of JBOWS (just a bunch of
> Web services) finally morphed at last in many organizations into
> more mature services landscapes with some actual governance. But now
> we see that the subsequent complexity, rarefied skills and tools,
> and additional constraints ended up stamping out a lot of SOA
> consumption at the edge. These days the evidence is beginning to
> mount (presented below) that a certain style of services -- combined
> with mechanisms that actively drive consumption and outfitted with
> real business models -- could address this. There are other emerging
> solutions to drive consumption of SOA as well. Without consumption
> and uptake, SOA cannot access the "return" in ROI. Systematic
> removal of the obstacles to participation in SOA is the goal in this
> view.
>
> The Spectrum of Service-Oriented Approaches: SOA & Web-Oriented
> Architecture (WOA)
> <http://www.ebizq.net/blogs/enterprise/images/soa_woa_spectrum.png>
>
> 3. *The focus on SOA still tends to be on the /[over]engineering of
> seams and processes/ instead of removing constraints on the business
> and increasing ready access to value.* We are still not providing
> good enough reach to our enterprise data, IT systems, or people.
> Despite heavy investments in IT for 30 years and the openness and
> interoperability intents of SOA, the majority of our enterprise data
> remains submerged and inaccessible to most business users, silos are
> still prevalent, and there still lacks the human dimension, the
> latter which can represent the use of more effective architectures
> of participation or the involvement of more than IT in the strategic
> development of SOA.
>
> While important cross-cutting concerns -- like security efforts or
> the imposed siloed architectures of enterprise software suites (ERP,
> CRM, HRM, etc) or even turf boundaries (see Conway's Law
> <http://en.wikipedia.org/wiki/Conway%27s_Law>) -- are also
> responsible for many of these issues, at the core seems to be a
> project-oriented focus instead of a product-oriented focus with SOA.
> This is not to say that good engineering is not important, but that
> we are too often aiming at the wrong part of the SOA tolerance
> continuum
>
<http://web2.socialcomputingjournal.com/tolerance_and_experience_continuums.htm>.
>
>
> Looking to successful models of SOA for answers
>
> As an industry it's also apparent that we have too few examples of
> good SOA to point to and use as reference models. Most success
> stories are behind the walls of other organizations that are just as
> inclined to keep the secrets of success to themselves. Best
> practices and effective approaches therefore are not always likely
> to spread when they should. In fact, it's fairly easy to argue that
> the evolution of SOA has often moved far faster in standards bodies
> than by validation of effective new ideas in the field that are only
> then adopted and standardized when they work well.
>
> Interestingly, this means the openness and visibility of today's
> modern Web seems to provide living examples of what's effective at
> driving forward business results with SOA. By this I mean when it
> addresses the key issues around improving the response to
> opportunities and directly enabling self-service, all while
> remaining highly scalable and protecting users and data. While I've
> been writing about Web-Oriented Architecture (WOA)
> <http://blogs.zdnet.com/Hinchcliffe/?p=168> for some time now, it's
> in truth a parallel "track" for SOA that's evolved organically in
> the wilds of the online world to meet many of the same challenges
> that we have in our organizations today.
>
> *Related: Fixing Enterprise Architecture: Balancing the Forces of
> Change in the Modern Organization
>
<http://www.ebizq.net/blogs/enterprise/2009/09/fixing_enterprise_architecture.php>*
>
> Key to the story of WOA is that at least one critical feedback loop
> is present in online businesses that is much less evident in most
> SOA efforts today: Their business will fundamentally thrive or die
> based on the adoption of their services. Most new online businesses
> offer an API (the Web version of SOA) at the very outset these days
> and it's now common for the services themselves -- instead of the
> visual Web pages -- to be the dominant point of usage early on.
> Online firms offer APIs in easy to use formats and then market and
> evangelize them extensively precisely because there is an urgent
> need and these are the best ways to drive adoption. There is also
> more direct and immediate business value in this model since
> carefully measured use and consumption is /the/ yardstick by which
> online firms are measured. It's also what they monetize, an entire
> area that's seriously underdeveloped in enterprise SOA for both
> internal and external customers. This is a yardstick that would
> change a lot of what we focus on in SOA.
>
> Imagine how we might behave and prioritize our efforts if our
> success was largely based on the number of points and overall level
> of consumption of SOA services, internally as well as partners and
> customers. Unfortunately, as Joe McKendrick noted yesterday in "SOAs
> too big to fail
>
<http://www.ebizq.net/blogs/soainaction/2009/09/soas_too_big_to_fail.php>",
> we may be increasingly isolated from that pressure as the business
> becomes more and more dependent on SOA. Ironically, this seems to be
> encouraging an organizational structure (which often is the IT
> department itself) that is isolated from market pressures.
>
>
> How WOA can help SOA reach the next level of performance
>
> While there are certainly many aspects of WOA that need to have an
> enterprise context added to them to work for traditional businesses,
> you can see from the visual above that a successful and capable
> service-based approach has emerged naturally side-by-side with
> classical SOA. At their roots, they both have great commonalities
> (HTTP, interoperability, and recombinant software), and some key
> differences as well. Intriguingly however, these often line up with
> many of the issues we're now seeing holding back the next level in
> business performance of SOA:
>
> * *Responding to change faster.* Reducing execution chokepoints
> by making SOA more self-service (running your SOA like a
> business <http://blogs.zdnet.com/Hinchcliffe/?p=525>) by
> broader audiences in the organization.
> * *Increasing consumption.* Using new service delivery models
> that make SOA the easiest, cheapest, and fastest way to solve
> problems.
> * *Actively enabling access to value.* Opening up broad access
> to data and people using models such as deeply linked
> REST-based data webs and open supply chains. Adopt
> browser-based approaches to consumption such as enterprise
> mashups tools and user distributable widgets that project the
> SOA across the organization.
>
> We certainly don't need to throw away everything that we've done
> with SOA to achieve these performance improvements, far from it.
> However, we must change much of the focus on what we do and how we
> do it. There are also some key additions to technical approaches
> that will be required such as adopting enterprise REST, making IT
> systems more mashup friendly, and updating existing delivery models
> such as portals and intranets to be more malleable, self-service,
> and connected to SOA data and resources.
>
> The bottom line: Since many of the very best examples of SOA that
> works are the models we seeing being proven out in large scale on
> the Web, we must learn as much as we can from them (and the price is
> right, even the most compelling lessons here are free.) While
> enterprise SOA will never be identical to Internet-based WOA, we can
> borrow the best ideas from the success stories that have emerged on
> the Global SOA (which is what I call the service-enabled side of the
> Internet).
>
> We are also starting to see evidence that a more mature melding of
> Web-oriented service models with the enterprise is actually starting
> to happen. For example, an InformationWeek survey this year
>
<http://www.informationweek.com/news/showArticle.jhtml?articleID=214501922>
> showed that on the technical side of the SOA/WOA stack, SOAP
> adoption appears to be dropping in enterprises (54% a year ago to a
> projected 42% in the next 18 months) while REST is on the rise (14%
> to 24% over the same time frame). The recent announcement of the
> opening up of EMML <http://en.wikipedia.org/wiki/EMML> is also
> showing that WOA concepts around lightweight composite applications
> (mashups) have moved into SOA territory.
>
> While emerging initiatives such as JBOSS's REST-*
> <http://jboss.org/reststar> may or may not help with this
> transition, as more of the foundation of WOA is available in
> organizations, richer and more effective outcomes on the business
> side of the the WOA equation are possible as well. No doubt this
> will take years, but this evidence and others shows that we are
> already beginning to incorporate the lessons of WOA into
enterprise SOA.
>
> In an upcoming post, I'll look at emerging new SOA practices that
> are coming from other sources as well.>>
>
> You can find this at:
>
>
>
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.421 / Virus Database: 270.14.7/2422 - Release Date: 10/08/09 06:39:00
