|
|
| Service Oriented Enterprise |
|
|
Saturday, December 03, 2005 SCA and Location Coupling For some reason, I'm fairly obsessed with coupling. I've written a few things on the subject: Dynamic Coupling and A Coupling Index. I've been monitoring the progress of the IBM/BEA Service Component Architecture for quite some time now. One area of interest to me is the concept of 'spatial' or 'location' coupling (or decoupling, if you prefer). On many occasions, developers create a model whereby they make an assumption about the caller:
In our quest to progress down the decoupling continuum, the issue of 'location assumption' must be addressed. Hence I was quite pleased to see the following text in the SCA whitepaper: "Components and their service interfaces can be designed for purely local use by other components, or components can be designed for remote access, either from other parts of the business or from other businesses. Local components can use interfaces optimized to exploit the co-location of the service client and the service implementation. Services designed for remote use must take account of the potential for the client being connected over a remote link and so must offer interfaces that are compatible with this remoteness." I've been wondering... what will end up being a bigger event, the release of SOAP/WSDL or the release of SCA/SDO. Only time will tell. posted by jeff | 3:26 PM Refabricating Architecture I just finished reading the book, Refabricating Architecture. The book isn't about software; the domain is the architecture associated with 'building construction' (apartments, homes, etc.) I enjoy reading these books as part of a personal cross-training program. There are a couple items that I wanted to share: "The way to art in much twentieth century theory and practice would be by means of a thorough transformation of production. Architecture as a mass-produced product would transform both access and perception; it would become a thing, a commodity, a vernacular shelter for the twentieth century. Great architecture is today equated with art. Commodity, most believe is the creed of the philistine. It is possible, however, to see commodity instead as the crucible of art itself and to recognize the process engineer - not the design engineer - as the high priestess of this new art. It is not the engineer as the designer of artifacts that we applaud, but rather as a designer of processes that show the way forward in art." Authors, Kieran and Timberlake, go on to state: "The single most devastating consequence of modernism has been the embrace of a process that segregates designers from makers: The architect has been separated from the contractor, and the materials scientist has been isolated from the product engineer" First, let me state my position. I am interested in the commoditization of software architecture. I am embarrassed by the current state of voodoo architecture, wizard architects and clean-sheet implementations. Don't get me wrong, I'm not stating that we should quit inventing or innovating. There is a place for 'material scientists', just not inside of every Fortune 500 I.T. shop... SOA has the potential to act as the 'material enabler' of the commoditization of software architecture. Modern methodologies will act as the 'process enabler'. Pure and simple - this is my goal. I realize that wizard architects will refute this. They'll hate the concepts of the software factory, mass customization, template architecture and meet-in-the-middle methodologies (not top down). It attacks their creativity and their personal income potential. The true professionals however, will see the ultimate value and find the art in the discipline. posted by jeff | 7:34 AM Wednesday, November 30, 2005 I Hid the Turd Dear Mr. CIO, I regret to inform you that I've been hiding a massive turd from you and the business units for several years now. The turd is the "3-tiered silo application". The stench was horrid - I was forced to get some industrial grade air fresheners that I called "EAI and ETL". I feel very bad about this, as does my staff. Although, there were several times where you called us into meetings and we all had those 'shit-ass grins' on our face and you thought we were making fun of you - good news - we weren't, we were laughing about our hidden turd. But I don't take all the blame. You remember when you asked us to do 12 major initiatives and we told you that we didn't have the staff? Yea - well, we didn't. So we cranked out as much as we could and patched the crap together with messaging. From an architectural perspective, it's a freaking mess!! We've got data replication, batch transfers, multiple message formats, multiple transports, platforms, vendors - wow, I can't believe you didn't fire us!! The reason that we are 'coming clean' is because we believe we've found an answer. It turns out that using simple protocols and a network programming model that isn't vendor specific will allow us to build connected systems. Also - we discovered this other wacky thing - this new model called SOA actually aligns to the needs of the business. Now that we're being honest with each other, I feel it necessary to inform you that this SOA thing... is right, but - it actually takes a bunch of planning and architecture. It's like - ya-gotta-use-your-brain-kinda-stuff. And not to drop another bomb on you - but a bunch of these guys around here are morons. Now, I know that you have deep pockets and short arms and don't like to pay for real talent, but I think your screwed if you don't. So, it's your call. In the meantime, the Turd guys, came up with this new turd-containment concept that they call an ESB. I don't know what it stands for but I talked to some smart guys and they said that it was supposed to be SOA but the vendors missed their deadlines - so they just repackaged their old turds with some new SOA stuff. So, just beware - were probably going forward with the turd-containment stuff and later we'll have to go with real SOA stuff. Sorry for hitting you with all of this. Sincerely, Your Entire Staff posted by jeff | 6:29 PM Monday, November 28, 2005 Requirements & Specifications in Service Oriented Systems I couldn't help but notice that the cover story for CIO magazine was about the requirements process and the awful state that it is in. I tend to agree. When I visit customers I see one of two things: 1. The company has perfected requirements for silo based systems 2. The company stinks at requirements all together I've looked at many systems that people wanted to upgrade, rewrite or replace using service oriented techniques. As a habit, I ask for the original requirements document for the production system. I then play this game to see if I can trace 'silo' or 'closed' characteristics back to the orignial requirements and specifications. In general, these characteristics are usually described in the 'supplementary specification' or in a supplemental 'non-functional requirements' document. And in virtually every case I am able to trace the issues back to the original documents. One of the significant changes in the 'service oriented enterprise' is an renewed emphasis on: portfolios, product lines, business processes, enterprise requirements and cross-cutting concerns. We are stressing to our customers that they MUST revisit the requirements process and move to an 'enterprise grade' method. That said, I am proud to announce a new course from MomentumSI, "Requirements & Specifications in Service Oriented Systems" The course is directed at the Business Analyst, but would valuable for anyone that participates in the requirements & specification activities. Course Outline
I firmly believe that those companies that continue to use 'silo based' requirements processes will fail in adopting SOA. We will begin offering this course in January. If you're interested in the full course description, just send Alex an email: arosen [at] momentumsi.com posted by jeff | 6:30 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
