Darrell and Sam both posted a couple of goodcomments in response to my rather rhetorically charged post on Everything’sa Platform.

Darrell’s point, if I may summarize, was that unbounded extensibility isexpensive. I agree, and I’d even go further – unbounded extensibilityis not only expensive, it’s a really bad way to build software. Too manyextensibility points lead to too many moving parts, and eventually you get to apoint where you can’t change anything without breaking something. Insteadof unbounded extensibility, you want clearly defined abstraction barriers. Youwant to make a clear delineation between “internal” and “external”,so that the two can vary independently. And you want to keep theseextensibility points to a strategic minimum, so that you expose only theinteresting stuff while hiding the mundane details. I think that if you adoptservices as a metaphor from the beginning, your architecture will evolve insuch a way as to make identifying these kinds of strategic extension pointsmore natural.

Once you’ve identified the boundaries within your application, you have awhole range of options on how you want to cross them. I don’t think thatidentifying a service boundary within an app necessarily means that you need toimmediately go through a Big Design Up Front phase to figure out how to crossit. Depending on the goals of your project, you might choose to acknowledgethat the boundary exists and let the interface evolve somewhat organically. Simplyknowing that a boundary is being crossed will influence the design positivelyto some degree, and you can always come back and spend later iterationspolishing up the wire contract should such a need arise. My argument is thatyou’ll see benefits from drawing those boundaries earlier rather thanlater, not that you have to scope out every detail of those interfaces RightNow.  

To Sam’s point about YAGNI: the YAGNI principle is about being strategicabout your development, so that you don’t waste cycles solving hard problemsyou don't really need to solve. If those problems are easy, calling YAGNI isless important. It’s in this area where I think service-oriented tools likeIndigo can really add value. Right now, implementing a strong service boundaryis more work than it needs to be. There’s still too much focus onplumbing details if you need to think about security and reliability. Robustlycrossing a service boundary via web services today involves a non-trivialamount of work – even if your app architecture is already built withservices in mind. As such, YAGNI is a perfectly reasonable response to serviceconstruction today. However, as the tools progress, the amount of plumbing workrequired to implement secure, reliable, transacted services will diminishgreatly. When your tools make “flipping the switch” betweenspanning a service boundary in memory and spanning that boundary across anetwork almost trivially easy, calling YAGNI is much less compelling. In thetime it takes you to explain why YAGNI, it’s already implemented J If the tools are solid, the controllingquestion around exposing a service to the outside world is not ‘why?’but ‘why not?’.

Of course, tools will only help you if you’ve already made thearchitectural commitment to use services as the organizational metaphor foryour application. Again, my argument is that there is value to be had inadopting this architectural metaphor early in the lifecycle, even if you don’tfully realize the underlying service plumbing until you have a concretemotivation to do so in the future.