Architecture

The message from TechEd

Jay Glynn — Tue, 14 Jun 2005 09:09:00 GMT

Without question the message from TechEd this year was services. How to migrate services, how to make services, how to use data in services etc etc etc. However, a comment was made in the BOF session I hosted that has me thinking. The question came up that since his organization is trying to move to service based architecture, he has found that the design of the application is changing. Instead of having a nice pluimp object model, he said he now is just pumping messages around. His problem was that he wasn't sure if that is what he should be doing. My first reaction was if that's what the situation calls for, then your doing the right thing. However as I thought this over for a while I'm starting to question that. I see where services are a “Good Thing”. But part of the reason for services is flexibility. In our organization flexibility means that the object or component might be implemented in a server based application or on a disconnected mobile device. In that case disregarding that nice plump object model may be a mistake. If I'm on that disconnected mobile devoce, services are worthless. I'll be saving data to a local database and forwarding changes later in batch mode. I'll need that object model. If that component is implemented on a server, a service facade could be placed over it.

The point to all of this is that we are hearing a lot about why to do services and how to do services, but we aren't hearing alot about the design of the business entity that the service will be servicing. Are we supposed to change the design of the entity like the person at the BOF session was describing, or is it better to do business entities just as we have been doing and wrap them up in a service layer? I'm feeling that the later may be the better option.

Pragmatic Architecture BOF

Jay Glynn — Thu, 09 Jun 2005 18:44:00 GMT

I hosted the Pragmatic Architecture BOF session last night and it turned out to be a really great session. There was some great discussion about when and if SOA is the correct answer, how to deal with upper management on determining the right way to implement and architecture and how does an architect stay current on the technologies. It was satisfying for me to know that others are struggling wioth the same questions that we are regarding the "right thing" to do.

SOA and OASIS

Jay Glynn — Thu, 02 Jun 2005 08:21:00 GMT

I read in SD Times today that OASIS is going to define SOA for us. From the article:

Just what is and what is not part of a service-oriented architecture is the subject of the latest work the Organization for the Advancement of Structured Information Standards (OASIS) is pursuing

Another quote:

Writing a specialization of SOA for electronic business was going to get difficult because a generalized definition of SOA didn’t exist

They are comparing this process to describing the parts of a car. Where the parts are and how they relate to each other in the overall function of the car. They said the reference model should be completed by the end of the calendar year. I feel so much better now. We'll finally have someone that tell us exactly what SOA is (and how the driveshaft is connected to the axel).

BOF Session Accepted

Jay Glynn — Wed, 27 Apr 2005 20:06:00 GMT

My TechEd BOF session Pragmatic Architecture has been accepted. It's currently scheduled for Wed, June 8th at 7:45. I am really looking forward to this. Application, system and enterprise architecture are taken for granted way to often. It's not about SOA, agile, TDD etc etc etc, it's all about doing the “Right Thing”. Hope to see many of you there to take part in the discussion.

Pragmatic Architecture

Jay Glynn — Sat, 05 Mar 2005 02:04:00 GMT

Over the past couple of years I have been noticing a trend that concerns me somewhat. Developers and architects have been designing application architectures based on buzz-words instead of based on the requirements of the user or the system. SOA is a prime example of this. I look around our enterprise and I see hundreds of systems. Some would say that I need to hook some of these systems together (many do talk to each other) using a service based architecture. Now if I look really REALLY close at these systems it becomes apparent that putting a service on some of these systems makes absolutely no sense at all. The technology just isn't built with a service in mind. Some of these systems may be 10 years old, but they work well and there are no plans to update or replace them. I still need to communicate with this system, but perhaps a client server type architecture would serve my purpose better. Why shouldn't I use it? Should I try and force an architecture in just because it's the trendy way to do things?

Does it seem that architectures are being based on what shows up in the latest magazine instead of what the system requires? I reached the point that I submitted a BoF session for TechEd to talk about this subject. If you feel the same, or would like to tell me that I'm crazy vote for the session and let's discuss it. Here is the link to vote.

Moving to v2.0

Jay Glynn — Fri, 25 Feb 2005 00:46:00 GMT

I have seen a couple of posts recently about moving code bases to v2.0 of the .NET framework when it becomes available. One that caught my eye was by Sahil. Two things struck me about the post. First the title, “.NET 1.1 Folks Please Take Note”. Aren't we all 1.1 folks at the moment. Last I looked there wasn't a go live license available yet. But more to the point is the comment about making sure your current code will work with 2.0. In the exchange of comments he made the statement to the effect that if I know the function X won't be there anymore, then I shouldn't use function X now.

Well here is my problem with this. I work in a large corporate environment. Any new technologies have to go through a long and rigorous testing process before they will be approved. So given that v2.0 won't be released until Spring/Summer of 2005 it will be at least 2006 before I could recommend it for a production application. Even then the apps that we have currently working in production won't be automatically be upgraded to run with 2.0. I can't justify the expense of re-testing and distribution for no real gain for the end user. So whether function X is available in a future version or not is irrelevent to what I doing today. I have to design for what is available today, not what might be available tomorrow. We don't even know for sure what functions will and won't be there. I have worked on 3 books based on beta .NET software and have had to make changes in all of them when they were released. Even from beta 2 to production things will change.

Just because we get a shiney new toy from Microsoft we must be prudent about moving everything we work on to the new version. Sometimes it just really doesn't make financial sense to make the move. As developers we all want to work with the newest and best technology that we can. But we also have a major responsibility to our customer to make the best fiscal decisions. I still support a lot of VB6.0 code, and will continue to for at least the next 2 years. We need to be aware of the newer technologies. I certainly am. I'm working on a book based on v2.0. But the rpoduction code I work on today is firmly based on what 1.1 has to offer, nothing more, nothing less.

Rocky does it again

Jay Glynn — Thu, 23 Dec 2004 20:32:00 GMT

Haven't been posting much lately due to deadlines by publishers, project managers and being the coach of my son's hockey team, but Rocky Lhotka has once again hit the nail on the head. Maybe because I'm one of the object-oriented guys he talks about. I absolutely hate datasets floating around in an application. Bottom line is that the traction that SOA has at the moment will pass when everyone realizes that most business software developed today doesn't really gain anything from it.

Migrating Architectures

Jay Glynn — Wed, 07 Jul 2004 05:40:00 GMT

James Greenwood has a post that raises an interesting question. His premise is that having a good architecture can actually be bad since it makes it difficult to justify migrating to new architecture. Now there is a bit more to his post then that, but this is an interesting point. When I do the architect role, the goal is to develop something that will pass the test of time. So, do I architect in the capabilities to migrate to the next sexy architecture of the day? Of course not. How can I if I don't know what that architecture will look like. If I look at a system that I might have worked on say 5 years ago, did I lay the groundwork to migrate to SOA? No because SOA wasn't the thing to do at that time. Few if any had even heard of the term SOA so how could I possibly design a migration path. James makes the point that a good architecture should support change. Nobody can nor should argue that point, but what change should it be able to support? Should it be the ability to migrate to a newer and possibly better architecture or to be flexible enough to solve an evolving business need? If the business need is met, is a newer architecture even required. I look at one of my responsibilities to be making the best use of the business area's money. They want certian problems resolved by the systems that I build. The business doesn't care how that happens. And they certainly don't want to spend more money and not have anything new to show for it just so that I can say we do SOA or whatever architecture is popular at the time.

SOA thoughts

Jay Glynn — Fri, 18 Jun 2004 17:59:00 GMT

There's been a lot of discussion on SOA lately. Two topics in particular have been turning around in my mind, web services and what to return. I go for a bike ride on most mornings and this moring some thoughts on this started to come together some time around mile 5. The two subjects are actually relatated and this is the part that I wasn't seeing at first.

First, in order to called SOA, some would have you believe that the only way to implement this is by using web services. I think this is a very narrow minded view on what a service can be. Web services are certainly an easy way to implement a SOA. But it certainly is not the only way. We have a gateway product the sits in front of our host system. This host system is running a 20+ year old policy admin system that is developed in COBOL and assembler. This gateway product translates a call from the client side to a CICS program that can then run and do virtually anything. When I write code against this product I interact with it as if it were a stored procedure. That is the syntax that I use. Now I consider this to be a service oriented architecture. Does this adhere to the 4 tenets of SOA:

Boundaries are explicit
Services are autonomous
Services share schema nad contract, not class
Service compatibility determined based on policy

I think that you could make an argument on all of them. The gateway serves as the service provider to a couple of million lines of COBOL. The same procedure calls have been made by multiple programming languages in several different types of applications. Not a single web service to be found. Could we put web services in front of this? Sure but why would we? What would that accomplish? Another layer of abstraction isn't always a good thing.

The other thing that keeps bouncing around in my head is what should be returned. This is much more difficult. In the example that I just layed out, the return is different depending on what called it. The layer of abstraction in this case is ODBC. I think that this will always be the case. There is no correct answer on what should or should not be returned. SOA is ultimately about integration. Otherwise why bother. So depending on what you want to integrate would depend on what you want to return. If you want ultimate flexibility you would have to return a deliminated text file of data. Almost any type of system or environment can at least read and parse this (even our 20+ year old policy admin system). The next step would be XML, the next would be XML with some type of schema. Next up the ladder would be XML in a SOAP or WSE package. Finally you get to return typed objects. As each step up the ladder occurs a limitation is placed on what can take advantage of the service. Now I have skipped several different types of data structures that can be returned, but I think the point is made. This is why I think you have to be very careful when laying out any new system. Implementing a bunch of web services and then standing back and saying your doing SOA is wrong and potentially dangerous. And this is where the two subjects tie together. If you use only web services for the service layer then you could be making it more difficult for some to consume the service. Returning a serialized .NET business object or even worse a dataset makes this service less useable to someone using VB6 to consume it. Yes it is only XML, but have looked at the XML that is spit out in those situations? And the point is to make the service easy to use.

The point of all this rambling is that caution should be used in implementing a service oriented architecture. If integration is not a requirement, then architect the application in the best way to solve the stated business requirement. Don't wrap everything up in a web service unless there is a specific need for a web service. If an integration layer is part of the requirement, then it should architected as that, an integration layer. Don't let the intergration drive to much of tha application architecture or else the original business requirement will suffer. Having a service oriented architecture is worthless if the business processes underneath the services do not accomplish the desired effect.

Tactical vs Strategic Unit Testing

Jay Glynn — Sun, 06 Jun 2004 17:52:00 GMT

Steven Cohn has a post Risk Based Unit Testing in which he describes the difference between tactical vs strategic unit testing. Tactical would be along the lines of TDD in which almost every individual method and property has a test written for it. Strategic would be testing the logical business case. This level of testing would actually test several method and property calls. The point being the test isn't as concerned with each individual method call, but the end result of making several method call. If a test fails, then a finer grain appraoch can be taken.

The point if this is developer and project productivity. Writing thousands of lines of test code when in reality hundreds will work means that the business user has their new toy sooner. To quote from Steven's post:

When I throw my code over the wall to the QA group, they don't care if my sorting method works. They want to know if the application works. So, to me, the challenge is making sure that I understand what's expected of the application at a higher strategic level and then prove it. This will speed up the development/QA cycles, make QA happier, which will make my life easier, which gives me more time to write these largely unread, ignored blog entries.