I'm not so sure about whether flexibility and evolution are in the same category as scalability and security.
Functional MEANS the flexibility and evolution, those are clear functional requirements of a system, its just that IT tends to see them as non-functional. The reality is that this is the whole point for the business in that they want a system that does X on day 1 and then does X+1, X+2, X+3 etc over the subsequent weeks. What IT delivers is a system that can do X and which in a years time can do X+1+2+3+4+5+6+7 and then a year after that can add a few more pieces at an ever declining rate. So I completely agree that evolution is key, but I disagree that it is a non-functional aspect. Steve 2009/10/8 Dennis Djenfer <[email protected]> > > > I don't think the functional things are any big problem, at least if we > only look at wich functions the business needs right now. It's the > "non-functional" things that are the core problem. How do you handle > security, scalabiltiy, usability, managebility and changeability (including > flexibility and evolvability)? That's where the problem begins. Especially > security and changeability are big problems for most enterprises. My number > one question for the last couple of years have been: How do you design an > IT-system and a portfolio of IT-systems that EASILY evolves and changes > along the same path as the business itself? > > // Dennis Djenfer > > > Steve Jones wrote: > > +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]> > >> >> >> 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] <jones.steveg%40gmail.com>> >> > *To:* service-orientated-architecture >> > <[email protected]<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 >> > <mailto:[email protected] <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 > > > > >
