Good work. As troll bait goes, very thoughtful =) I think the three patterns in EA that matter are the Service Pattern, the Process Pattern and the Event Pattern.
I agree that "SOA" focuses narrowly on the service pattern--but it doesnt have to. It's still possible to take an "outside in" view of service. Meaning that the definition of service is more closely related to the concept of how you are serving external constituencies. The word "external" in this context could mean the guys down the hall or it could mean a bona fide customer (or citizen in the case of government agencies). Looking at it from this view, the design center becomes "how can we *serve* better". This involves process pattern and event pattern also as well as the service pattern. I think this is what people are reaching for these days which is a better sense of balance and to understand the boundaries and limitations of a "service only" view of the world. Miko --- In [email protected], "Rob Eamon" <[EMAIL PROTECTED]> wrote: > > We've been a quiet group of late! Here's a rake for the muck.... > > A Joe McKendrick blog entry covers the question, "Is it time to fold > SOA into Enterprise Architecture (EA)?" > > http://blogs.zdnet.com/service-oriented/?p=1054 > > The article states that SOA, EA and BPM are all the same and have all > the same underpinnings. > > Are people finally realizing that SOA isn't a new area in and of > itself? Is this the beginning of the end for SOA being at the center of > attention? I can only hope so. :-) > > Recall that service orientation was first applied to application > design, at least according to Gartner literature. Building applications > as a set of coarse-grained, business level services in which the > interface was independent of the implementation would lead to a more > flexible and adaptive application. > > Many people took this same concept and said "Hey! That would work at an > enterprise level too!" Indeed, this notion applied at the enterprise > level should provide even greater benefits. The promises of service > orientation don't really pay off well at just the application level--it > needs to span the enterprise. If we can get solutions built around the > notion of services instead of the silos of applications, then we should > see great benefits in terms of speed to solution, flexibility, etc. > > [sidebar] The listed SOA benefits often includes all the usual benefit > suspects touted for every new thing that comes along. Procedural > languages, 4GLs, client/server, OO, EAI, web services, XML, et. al. > were all going to save the world! We'll have the IT environment we need > and business people can specify it all with just a few mouse clicks! No > need for those pesky IT people! ;-) Does anyone remember how SQL was > positioned as a tool for the average business user to unlock all the > data they would ever need? > [/sidebar] > > Other folks saw this service level focus and thought it applied best at > the business level. What a great idea! Describing the business in terms > of services seems to be a very natural fit. People can really wrap > their heads around that. And this business level structure should map > quite nicely onto service oriented technical structures. Brilliant! > > Here's the challenge: Each of those levels wants to use the term SOA. > > IMO, none of them should. Those levels already had terms: application > architecture, enterprise architecture and business architecture. Each > of them can follow service oriented principles. Each of them will > follow other principles as well. SOA doesn't introduce another level of > design. Rather, it modifies how we approach the design levels we > already use. > > Business level design, mapping of business constructs to technical > constructs, governance, etc. all need to happen, whether they follow > service oriented principles or not. > > Service orientation changes the how of performing these things but > let's not lose sight of the fact that they were needed long before SOA > came on stage and will be needed long after SOA is but a distant memory. > > [one last sidebar rant] Governance is an important piece. SOA > governance, if it exists as separate entity at all, is a subset of > governance. All the focus on "SOA governance" can be dangerous, IMO. An > enterprise might have a great SOA governance plan in place, but what > about the rest of the enterprise? > > Do the components that are not service oriented (you know, those little > apps that are key to the business and are running on the mainframe and > push data around using flat files) need governance too? Yes they do, so > I think we should be focusing on enterprise governance, not SOA > governance. Registries and service discovery are great and all but > let's not forget about the rest of the enterprise. Ideally, everthing > would be service enabled and thus SOA governance == governance. But > we're not quite there yet, right? :-) > [/sidebar] > > Long live service oriented! But SOA must die! :-) > > -Rob >
