Pete Lacey’s Weblog

So, I took Mike up on his offer. Starting this coming Monday, January 7th, 2008, I will be a full time employee of Collaborative Software Initiative. This was not a terribly easy decision to make because at virtually the same time that I was talking to Mike, Burton Group, my current employer, asked me to step up to an analyst position and help make 2008 the year of REST. Had the timing been just a little bit different, I would have happily went that route. But as it is, after nearly three and a half years of fighting the good fight privately and publicly, and just as the message is starting to resonate, I’m moving on.

Why? Short answer: it’s time to shut up and code. Even though I was a consultant at Burton Group, my deliverables were reports. “Here’s 30 pages on how you might want to re-architect your software. Here’s 40 pages on why ESBs suck. Here’s 25 pages stating that yes, you can run PeopleSoft on Linux. ” Don’t get me wrong, these were mostly fun projects, but, man, sometimes you just gotta code. I can’t feel good about my work for customers or even my opinions here on this blog, if it’s been 3, 5, 10 years since I moved an app into production. And an analyst position, while prestigious and to some degree influential, doesn’t change that.

Of course, if it was just coding I was after, I could have taken a development job at BigBank or BigPharma, but the CSI gig is more than that. CSI has a unique and appealing (especially to this freetard) business model. The short of it is as follows: You, BigBank or BigPhara or BigManufacturer, require the use of a lot of domain specific software that affords you no competitive advantage; say to satisfy regulatory requirements. Now you could develop this in house, and that would cost you a $1,000,000. Or you could outsource it to Elbonia, but that’s still $500,000 and you never really know about quality. And in both cases you’re stuck with hosting and maintaining that codebase for a very long time. Or you could collaborate with others in your industry (remember this software has no competitive advantage), chip in some smaller number of dollars, and CSI will do it for you—professionally—and with you very much part of the project team. Not only that, we’ll be using open source tools the whole way. Indeed, the final product will be open source (that’s the cool bit, BTW), so that as development continues by CSI, yourselves, or your competitors—whether they payed to play or not—you benefit. Sure, someone could make changes locally and not give them back, but really we’re talking about compliance issues and other boring, non-competitive things, so why bother?

Back to the analyst thing for a moment. Research and Analysis (R&A) firms can provide a very valuable service, especially if you are largely unfamiliar with the wherefores and whatnots of a particular technology domain. For instance, Burton Group has a relatively new Data Center Strategies service whose content is, to me, someone who knows next to nothing about SANs and virtualization and ITIL, deeply informative. Burton Group also differs greatly from the big name R&A firms in that, by and large, our content is extremely technical and aimed at a technical audience. Nor do we attempt to cover every aspect of the technology industry, such as microprocessors, consumer technologies, or ERP systems. And we do not write reports for a fee. Furthermore, our analysts are, to a person, ridiculously smart. Thus, our customers get the focused and well-reasoned guidance they pay for. Plus the convenience of not having to go looking for it themselves.

That said, our analysts are human. They have biases, imperfect knowledge, and limited viewpoints just as we all do. These human foibles may not be significant when it comes to networking or telecoms or managing the data center (maybe they are, don’t know), but when it comes to the somewhat more subjective world of software development, application design, and enterprise architecture, the ramifications can be significant. Furthermore, R&A firms suffer from the very real problem of being a largely one-way medium: we write it, you read it, with limited feedback, little fine-tuning, and little exposure to alternative thinking. In addition, and for obvious reasons, most R&A content lives behind a pay wall, which to me at least seems like a pretty limiting means of promoting knowledge and effecting change in the enterprise, among vendors, and in the world at large. I would go so far as to say that Sam Ruby’s blog, for instance, has done more to change the world than the millions of pages minted by R&A firms that only a select few get to read.

However, the path from Sam’s blog to the enterprise is circuitous. In an ideal world enterprise technologists, from senior management on down, would be subscribed to that section of the blogosphere that is related to their trade; they can buy the same books, read the same papers, and attend the same conferences. But by and large they still don’t hear you. Instead, as Sam wrangles with Unicode issues in Ruby 1.9, Ruby improves and awareness is raised that Unicode is indeed tractable. And soon it becomes the norm that English/Western biases are no longer acceptable. Also, because Ruby improves, Rails improves. As Rails (or Merb or whatever) grows in popularity, so too does iterative development, a focus on testing, a recognition that dynamic languages are not toys. Then the vendors start adding DRY principles to their products, adding support for Ruby and Python, recognizing that REST really makes sense. And then, finally, these notions begin to trickle into the enterprise such that it starts to look like the rest of the world did ten years prior.

In short, the R&A industry can and does provide valuable information, all nicely consolidated. And the content produced is formulated perfectly for the chosen consumer. But, at least as it pertains to software development, if you’re looking for timely, informed, and practical information from the people who are actually doing it, nothing beats the continuous feedback loop of the Web. Your job is to find the signal in the noise and make your own informed decisions.

Now it’s time to install Ubuntu onto my new Thinkpad.

By the way, you may be wondering how I got this job. Here’s how.

I know my previous post was on how great a book Release It! is, but have you subscribed to Michael’s blog, Wide Awake Developers? In particular, did you see Budgetecture and its ugly cousins? Beautiful. There’s lots of fun quotes in this short post, but here’s the one I like best.

Of course, if databases didn’t cost so much, nobody would care how many of them there are. Which is why MySQL, Postgres, SQLite, and the others are really so useful. It’s not an issue to create twenty or thirty instances of a free database. There’s no need to collect them up into a grand “enterprise data architecture”. In fact, exactly the opposite is true. You can finally let independent business units evolve independently. Independent services can own their own data stores, and never let other applications stick their fingers into its guts.

Oh, boy! This is good stuff.

Based on Steve’s glowing review, I ordered a copy of “Release It!” And, wow! What Steve said. This is an extremely readable and informative book that every enterprise developer should read. But rather than heap more praise on Mr. Nygard, I thought I’d present here a few choice quote that resonated well with my RESTian world view.

Cynical software expects bad things to happen and is never surprised when they do.

The more tightly coupled the architecture, the greater the chance that [a] coding error can propagate. Conversely, the less coupled architectures act as shock absorbers, diminishing the effects of [an] error instead of amplifying them.

Your best bet is to keep as little in the session as possible. [Nothing, really. Ed.]

Hope is not a design method. [Sounds familiar. Ed.]

[This next one I’ll quote at length. Ideally, we should have all learned this a long time ago, but sadly that’s not the case. Ed.]

Integration point latency can be a serious performance problem. The problem becomes acute when the integration point uses some flavor of remote object protocol. The “location transparency” philosophy for remote objects claims that a caller should be unaware of the difference between a local call and a remote call. This philosophy has been widely discredited for two major reasons. First, remote calls exhibit different failure modes than local calls. They are vulnerable to network failures, failure in the remote process, and version mismatch between the caller and server, to name a few. Second, location transparency leads developers to design remote object interfaces the same way they would design local objects, resulting in a chatty interface. Such designs use multiple method calls for a single interaction. Each method call incurs its own latency penalty. The cumulative effect is a very slow response time.

A system that cannot adapt to its environment is stillborn

If this group [of enterprisey, ivory tower architects] has power, they will put projects on hold until the enterprise architecture is defined. If they do not have power, they will gnaw on their own livers as project after nonconforming project rolls into production without the benefit of their architecture.

Nothing hobbles a system’s ability to adapt quite like having other systems poking into its guts.

Clearly, there is value in avoiding this [tight] coupling [between systems]. It has undesirable effects on the time to market, deployment cost, and system availability. We must design protocols so that either endpoint can change independently of the other. [Or properly use one we already have. Ed.]

Of course, not every sentence rings as true as these. Here are two that fell a little flat.

When that invisible machinery [application servers magically dealing with cookies and sessions] involves layers of kludges meant to make HTTP look like a real application protocol, it can really tip over badly.

It’s understood that what Mike really meant to say was “… make HTTP look like a more familiar application protocol.”

The sad truth is that HTTP doesn’t handshake well. HTTP-based protocols, such as XML-RPC or WS-I Basic, have few options available for handshaking.

Again, to put words in Mike’s mouth, what he meant to say is that “Protocols that tunnel over HTTP, such as XML-RPC or WS-I Basic, have few options available for handshaking.”

BTW, what Mike means by handshaking in this regard is the ability for a server to protect itself by “throttling its own workload” in cooperation with a client. HTTP actually has a sizable number of mechanisms for limiting resource consumption including:

• Caching and conditional GETs
• Using HEAD and OPTIONS to query a server’s capabilities before attempting to use them
• Politely putting off processing till later (202 Accepted)
• Sending the work elsewhere (303 See Other, 305 Use Proxy, 307 Temporary Redirect)
• Simply refusing the work (503 Service Unavailable)
• Using “look-before-you-leap-requests” (Expect: 100 Continue)

Admittedly, some clients and servers are better than others at properly implementing support for these features, but that’s not to say they’re not there.

But none of this last bit is to say that “Release It!” is flawed. These are just two (and the only two) picayune things I could find. In every respect “Release It!” is just fantastic and is a must read for anyone developing enterprise apps. Not only does it have lots of fun, pithy quotes and entertaining war stories, it has real practical advice on how to create production ready software. Buy it!

Like most other Americans living remotely from the family nexus, I traveled home for Thanksgiving. While talking to my brother, he mentioned that “Joe (not his real name) said to say thanks for the advice. He followed it and now he’s doing very well.” It took a moment to jog my memory, but the “advice” was an email I sent to a colleague of my brother’s on how to position himself for a job in the technology sector. I dug up the email I sent nearly three years ago and found that it’s still largely applicable, so I’m posting it here. What advice would you give to the query that follows?

The Query (The subject of this post is the same as the email. My brother is retired from the Army, but still in the reserves as a Lt. Colonel.)

You told me to shoot you an email that you could forward to your brother, here it is. I still plan to give you a resume, but I don’t have that ready yet. This is more of a question about what knowledge to start building, and hopefully in what order. I don’t have a perfectly clear plan of where I want to go with this career-wise, either (which makes part A harder) but I do know that I’m really enjoying learning/doing this stuff. So, let me start with that; what I have learned/done and which parts I enjoyed most. The question for your brother, I guess, is where to build my strengths, where formal training is better vs. self-taught stuff, and which certifications might be essential/nice to have/a waste of time to go with the strength-building part.

So, a bit about my coming of age with computers. My formal training prior to this mobilization was just in database design, with a little bit of project management/software life cycle (that sort of thing) thrown in. I taught myself Access, Excel, a bit of SQL, and Visual Basic for Apps in the intervening years between my degree and this mobilization, and I completed a few small DB projects during that time as well (the most complex one to date you saw, the one I did for the unit. For your brother’s edification, it was a secured Access db designed to be shared by 12 users over a network drive. Most of its forms were linked to the user logged in (i.e. who you are determined what you saw as well as what you could do at the DB level)). It’s not an enormous project (equivalent to, say, something a small business owner would use to track inventory and sales data, if he had multiple employees providing the inputs), but I learned a lot about VBA and security implementation while doing it, as there was sensitive info (privacy act stuff, mostly).

Most recently, I’ve been trained by the Army on basic network design (OSI model, components, programming Cisco devices, subnetting, etc. Something that’s probably about the 75% solution toward getting a CCNA, if I go that route). I’m also doing online and hands-on training w/ Win Server 2k3, Exchange Server 2k3 and SQL Server 2k3, all of which are used by the Army in support of its tactical systems.

I’ve enjoyed pretty much everything I’ve learned so far, though I’m just at the start of the power curve on the Server stuff. The stuff that grabs me the most, I think, is still database design, and some of the programming, though I’m finding myself curious about web-app development, though I have yet to pursue that with any vigor since it doesn’t relate to my current job.

I’m considering doing some freelance work via eLance, Guru.com, or the like, to gain some experience, but I’m not sure how far I’ll be able to take that in terms of making it a career. Likewise, I don’t know what I don’t know in terms of learning/training. For example, I thought an ‘easy’ way to expand on my current knowledge might be to pick up Visual Studio to be able to create runtime apps based on Office components. That, in turn, led me to think that learning C# or Java might be a good step toward the future, but I’m not sure. It seems that there are a lot of projects available online for guys who know mySQL, perl, and php. So that makes me think that might be the right direction to go.

Hence, my call for advice. Thanks in advance for your time/consideration.

The Response (gently edited for grammar)

Joe,

Disclaimer; I’m biased and not all knowing. This is a long, un-proofed email, skip to the end for a shot at a concrete suggestion.

A question for you; are you planning on leaving the military, and getting a civilian IT job? Is that where these questions stem from? If not, learn what the Army wants you to know, and enjoy a fairly secure job. If so, then…

There’s no one answer to your questions. A lot depend on your goals and affinities. Lets break probable career goals into three (non-military) categories:

1. Stability
2. Money
3. Job satisfaction

They’re not mutually exclusive, but any one of them may be more or less difficult to attain given your age and knowledge level.

Stability: Nothing is stable. Some things, however, are more stable than others. Government jobs tend to be more stable, but for less money and old technology. Jobs in finance offer the most money, have all the good toys, but require a lot of expertise and are not stable during economic downturns. Mom and pops get by with a few Windows machines, Excel, and a VB app. Etc. Answering these questions first can help with the rest. None of what follows consider Mom and Pops as there needs are simplistic. It assumes firms of several hundred to tens of thousands of employees. It also doesn’t consider actually working for technology companies (Microsoft, IBM, etc.), though consulting companies are valid.

Like me and many others, you get a charge out of all aspects of technology. And while its good (required) to know a little bit about everything, you will need to specialize. So lets break the IT world into two pieces:

1. Hardware
2. Software

Hardware, in this case, means the guys that are racking and stacking servers, routers, disk arrays and such. They care about networks, and security, and uptime. Software means writing code, testing, and deploying applications. It means administrating software servers; i.e. databases, application servers, directory servers, etc.

Pick one of these now. If you choose hardware, then it’s especially hard to learn on your own. You can read all you want, and that’s good, but ultimately you won’t be able to afford any of this stuff, so you’ll have to learn on the company dime. That means an entry level position while they get you training or just throw you into the deep end of the pool. My thinking is that at your age you probably can’t financially afford to do this. A CCNE is an especially valuable accreditation, but it’s expensive and difficult.

If you choose software, well, that’s infinitely malleable, and there’s lots of specialties. But we’ll continue narrowing things down. What follows might seem brazen, but it is really where the world is now.

1. Microsoft
2. Everyone else

You have already started down the Microsoft path, and that’s fine. For that reason you may consider staying there. If so, let’s break that down a little further:

a. Client
b. Server

So far, you seem to have most of your experience on the client side. You’ll want to know this as a matter of course, but you do not want to specialize in it. No growth, no money, and not what larger firms care about. Knowing Visual Basic, Access, Excel, Office components, etc. doesn’t hurt, but that’s either Mom and Pop technology or fully baked at larger firms. Deploying and securing Windows to the desktop is a different story, but I find that tortuous and uninteresting, you can decide on your own.

The server aspect of MS technology is much more interesting and financially rewarding, simply because its much more difficult and MS is in the process of reinventing their offering. In this case, it’s all about .NET. If you’re not familiar with it, it may be hard for you to really discern what .NET is; here’s how most people currently define it. The C# and Visual Basic programming languages, the Common Language Runtime (CLR, a virtual machine), the .NET libraries, and a boat-load of best practices and design principles; chiefly web services (aka SOAP). Now, just like any technology, you can write simplistic applications with this technology. But your real goal should be understanding enterprise application development. The problem is that there’s a very steep learning curve here as there’s lots of technology in play, plus 30 years of aggregated design practices. Also, a lot of what’s entailed will be pretty heady stuff for a self-starter with a non-programming background. However, that’s also true for the non-Microsoft camp.

If being a .NET developer is not of interest to you, then there are always MS platforms that need managing. You’ve got some experience here, and it may be the place you want to start. Specifically Exchange, SharePoint, and SQL Server. Of these, SQL Server is the closest to business application development, and employers might want more experience than you currently have. If this is of interest, though, let the army train you, and if that training is not sufficient, explore on your own. Also remember, that resumes can be very creative. If you want to get ahead of the curve SQL Server 2005 (Yukon, in beta) has support for a technology called XQuery. XQuery will be a very big thing, and very few people know about it. You might want to look closely at that, so that when the XQuery jobs come, you’ll be ahead of the game.

Finally, there’s managing an MS infrastructure. This is an IT function half-way between all hardware and all software. It means making all those back-end systems work together. Specially it means MS Active Directory, Win2K and 2003, file and print services, and so on. Note, though, that very few companies are 100% MS in the server room.

If I had to wager on a fight between MS and Everyone Else, I’d pick Everyone Else (Note, I have anti-Microsoft tendencies). Remember Everyone Else includes IBM, Oracle, Sun, HP, SAP, the open source community, and nearly all non-US governments. So how do we factor out the Everyone Else technology? Not surprisingly, since Microsoft’s offering “emulates” Everyone Else’s offering, they look very similar. Just do a little name substitution:

Windows -> Unix (Solaris, AIX, HP/UX, Linux (especially Linux)).
C# -> Java
CLR -> JVM
.NET -> Java/J2EE
Active Directory -> LDAP
SQL Server -> Oracle, DB/2, PostgreSQL/MySQL
ASP -> JSP/PHP
Exchange -> Sendmail/Postfix/etc.

Of course, it’s not really that simple. But I would highly suggest that you look closely at these technologies. It’s cheap (free), there’s a TON of information available online, and it’s going to make larger and larger inroads. In my opinion, MS has lost a lot of it’s ability to influence corporate decisions. Firms now recognize that an inexpensive Linux solution provides as much or more functionality than a corresponding MS solution for a LOT less money. This means that they’ll be a migration away from MS towards Linux (open source); a wave you can still catch. From your point of view, Linux costs you nothing, databases cost you nothing, application servers, IDE’s, compilers, web servers, mail servers, and so on ad nauseum cost you nothing. The barrier to entry is not high.

So, if you’ve chosen the non-MS side where do you go? Well the same dichotomies exist: programmer, administrator, etc. If you choose to program, then the choices are:

1. Java
2. Non-Java
3. Both

I highly recommend Both, but that’s a lot to bite off. Java developers are in high demand, especially J2EE developers (similar to .NET developers), that is those guys that write complex enterprise systems. J2EE is a lot to get your head around, but fortunately for you there’s a recent upswell of resentment to the complexity of J2EE, which is being addressed by simpler, equally effective, platforms. Since this is new and likely to be sustained, this is another rewarding wave to catch. So, if you’re intrigued, go take a look at the open source Spring Framework. If you want to stick with J2EE, go download the open source JBoss.

In the non-Java camp there’s basically:

1. C
2. C++
3. Scripting languages

You will not find too many entry level C/C++ positions, but from a personal growth perspective you should become familiar with C. You do not understand computers until you’ve done your own memory management. Avoid C++ at all cost. You really should become familiar with the scripting languages. None of them will make you much money in corporate America, but all sorts of interesting things are going on there, and Perl at least is a prerequisite for using Unix. You should glance at Perl, Python, PHP, and Ruby. You do not need to know all of them — I don’t — but you should be aware of them. At this point, I don’t think there’s a lot of money in PHP/MySQL development. The jobs you’re finding are project jobs, and, as yet, steady corporate work specifically around these technologies is not there. I could be wrong on that, though.

Okay, now the databases. Being a DBA is a unique position, again straddling the line between programmer, administrator, and Nazi. A highly skilled Oracle DBA is very valuable. Less skilled ones will find employment. If you just want to learn more about databases in general, check out PostgreSQL. Ignore MySQL as a learning resource, it’s popular, but it ain’t a “real” database. Go ahead and learn it though, as a lot of apps are built on top of it — not business apps, though.

The list goes on and on (like this email), so I’ll stop enumerating everything.

There is, of course, a lot of technology that crosses boundaries. I’m intrigued that you have software development management experience. A good manager is a valuable find. Fundamentally, good project management skills are mostly what you need. Technology wise, you should be familiar with the current thinking about the “Software Development Life Cycle.” In particular, “Agile” development. That means Unit Testing, continuous integration, iterative design, and more. You might want to learn UML & RUP, but I’m loathe to recommend that.

Also, learn the Web and Web app development, be it PHP, ASP, JSP or whatever, but really understand it.

Security is a job unto itself. In fact, it’s several. Implementations are technology dependent, but the concepts are generic. However, you really have to _earn_ your security wings.

Learn XML. Learn XML. Learn XML. In particular focus on the core XML spec, XML Schema, and XPath. Indulge in a little XQuery too. Also look at XML parsers and processors; Saxon, Xerces, Xalan, and so on.

Practice fundamental coding techniques, that is data structures and algorithms. In the language of your choice, implement a hash function, a quick sort, a linked list, etc. It provides a positive grounding, just like learning C does. In fact, do this in C and you will have really learned something.

As for certifications, I’ve never had any. Word on the street is that outside of Cisco’s they’re all worthless. Yes, you’ll learn something if you go in there cold or even warm, but they won’t prepare you for the real world. Certifications won’t hurt the resume, but probably won’t buy you much either.

That’s it for now. I know I rambled, but it’s not a question you can answer definitively, especially since I don’t know you. To summarize: Choose hardware or software. I can’t provide much guidance if you choose hardware. If software, choose Microsoft or the rest of the world. If MS, then learn .NET. If the rest of the world, learn Java and J2EE or Spring. Unless you want to be a DBA or IT administrator

If you want a more concrete recommendation, I would recommend that you choose a role of Software Development Manager. These are important, financially rewarding roles that very few people do well. Typically this post is offered to ex-programmers who have exactly the wrong temperament for the job. As I understand it, the army helps build good project management skills. In your case, you even have some experience in the SDLC. I would bolster that with a study of Agile development techniques and a glance at RUP. This is not a tech-lite position. You have to understand the technologies that the software is being built on (e.g., Java, Oracle, Linux), and you have to understand the tools the software is being built with (e.g., Eclipse, JUnit, Ant, Subversion). It’s a high-paying job and I think satisfying for people who can really manage process and people (I can’t).

If you want to talk, let me know. We can do it for free with Skype. My Skype ID is xxxxxx.

Good Luck,
Pete

After Thoughts

If I were giving the same advice today, I don’t think I’d change too much. In retrospect, I may have made too much of XQuery, but I was playing with it at the time. This was pre-Rails and the dynamic language revolution, so I’d alter my advice slightly regarding Python and Ruby. I wasn’t a full-blown RESTian then, either, but I don’t think that would have changed my advice too much. I certainly would not recommend today spending a lot of time with XSD.

Now, this is interesting: Google Code for Educators. Lectures, labs, and teaching materials on current technology trends, e.g. map/reduce.

Via: Ian Davis.

Is REST over-hyped?  Is WS-* viable?  Is SOA evil?  Stefan steps up to the plate with RESTafarian SOA Killers.

Update:  My slides are here.  However, they’re not as effective without the demo.

What’s left to say? It seems everyone who participated in the SOA track, as a speaker or attendee, has already posted their thoughts. And others who could not attend have run with Stefan’s notes (go backwards from that link to see them all).

From my POV, it was a fantastic two days. All of the RESTians on the SOA track had excellent (if somewhat overlapping) presentations. The lone non-dyed-in-the-wool REST proponent, Sanjeeva, had a—uhm, err, shall I say—provocative presentation. So lets talk about some of the other sessions I was able to attend. On the Ruby track Obie Fernandez gave a presentation on “Designing RESTful Rails Applications.” I knew most of what Obie had to say already, but still learned a thing or two, and also learned that there’s more to learn. Must peak into the routing code. It was a good talk nonetheless, especially if you were Rails proficient, but new to RESTful application design. James Cox also gave an informative talk (with examples!) of what’s new in Rails 2.0. And Jay Fields gave a wonderfully intriguing talk on using Ruby to build “Business Natural Languages.” That is, highly specialized, English-like DSLs that can be used by subject matter experts to implement business rules. This talk was not a “gee, wouldn’t it be nice” kinda thing either. He’s really built them. With great success.

Brian Zimmer, lead architect at Orbitz, gave a talk on the Architecture Track about growing Orbitz both from an infrastructure and design viewpoint as well as from a U.S.-centric to a globally-capable system. Brian was a good speaker, but I can’t say I learned much. Rule #1 seems to be, don’t code yourself into a corner with U.S.-centric assumptions. Rule #2 seems to be don’t architect yourself into a corner with bad design choices. Both true. Both hard. But what really moved this talk from “green” to “yellow” for me, was his discussion on caching. In order for Orbitz to not beat the crap out of their partner’s systems, they cache results for a period of time (presumably based on SLAs, since there’s no cache control info on the wire), but their original, home-grown, caching solution didn’t scale. Brian described this system via the metaphor of a block of mailboxes that you might see in a post office or apartment building that could only hold so much information and only for a specific partner. And my thought was, well, who the heck designed that? They resolved the problem by purchasing a commercial caching solution, but he wouldn’t say which one.

James Noble presented Thursday’s keynote “The Lego Hypothesis.” With a somewhat over-the-top presentation style, James said the right thing: Google is our software repository, and developers reuse code snippets and libraries just as people have been saying we should — albeit, without being weighed down by issues like “correctness.”

I arrived late on Wednesday and so could only take in two sessions. The first had Chet Haase, Erik Meijer (LINQ), Charlie Nutter (JRuby), Joshua Bloch (large pieces of Java), and Rod Johnson (Spring) debating the future of Java. Everyone was (obviously) knowledgeable and pragmatic. They did not, however, all agree. I felt myself leaning towards Charlie’s answers which can be summed up as “it’s up to you, now.” I also managed to attend Wednesday’s closing presentation, “50 in 50,” delivered by the eminent Dr. Richard Gabriel; a bizarre, delightful, entertaining multimedia romp through the history of programming languages. My favorite? HQ9+.

That’s it. A wonderful conference made better by being able to meet many people face to face for the first time, including not only my fellow track speakers but Stu Charlton, Mike Herrick, Patrick Logan, and many others.

This is a long-delayed post.

Next week is QCon San Francisco. Stefan generously offered me a slot in the “Connecting SOA and the Web: How much REST do we need” track, alongside Steve Vinoski, Sanjiva Weerawarana, Dan Diephouse, and other luminaries. Woot.

For my part, I’ll be demonstrating the “ilities” of REST. Yes, rather than just explain things and have the audience take my word for it, I’ll be showing running code of a real (albeit simple) RESTful application. Thus, for the last two weeks, I’ve been busily learning Rails and enjoying its support for REST. It’s a simple app, and if I knew when I started what I know now, it could have been done in a day or two. No loss, I’ll be able to leverage this time for the REST Workshops I deliver as part of my Burton Group gig.

Of course the intent of the demo is not to show off Rails (I don’t plan too) or to prove how leet I am (I’m not), but to put an emphasis on the fact that something as mundane as a Web application, when properly designed, leads to accessible information and evolvable systems. I’d love to demonstrate scalability and performance too, but, hey, I’ll only have one laptop with me. (Oh, and VMWare rocks.)

Hope to see you there.

So the battle still rages over on SOA Discuss. However, the list server seems to have crapped out. So, while I haven’t been an active participant by any means, I’m pulling this from my sent mail folder and posting it here.

Anne Thomas Manes wrote:

Previously I defined and redefined some terms to be used when discussing networked systems. With feedback from Sam Ruby, Josh Haberman (in the comments), and Steve Jones, plus smoe more thought on my part, I would like to present a more refined version of the same. With this post I’d like to introduce some new terms and revisit some old terms, all arranged in a taxonomical structure from most to least general. Note, the definitions given here will differ in places from those given earlier and from some defintions in general use.

Why bother? Principally because the terms in current use are heavily overloaded, especially SOA, which has at least three distinct definitions depending on who you ask. It’s my hope that some agreed upon terminology will help keep people from talking past each other and to better crystalize our thinking on the subject.

This taxonomy only addresses network programming models that are to be used for general-purpose systems. It does not care about anything below layer 7 of the OSI network model and it does not care abouut dedicated network protocols such as LDAP or SQL*Net.

At the top of the stack there is network-centric computing (NCC). NCC is the generally held belief by all interested parties: developers, architects, business analysts, and the business itslef, that exposing functionality directly on the network in a standard and interoperable manner is superior to building application silos. NCC is completely technology independent; it is an approach to systems design, a mind set. Why not just use the existing term distributed computing? Mainly because that term includes extremely tightly bound systems, including distributed systems that are in fact a single system that happens to reside on multiple machines; such as Oracle RAC, or systems that parralellize processing, such as SETI@home.

Next we have NCC designs that take into account the vagaries of the network. These are termed netwok-oriented computing (NOC) designs. NOC systems have incorporated into their design the fact that networks are not reliable, do not have zero latency, etc. In contrast, there are NCC designs that attempt to abstract the network away, such as system exhibits a network-independent computing (NIC) design. Such a design attempts to ease the burden on the developer by modelling remote systems as if they were local.

Either model can be further refined by applying an architectural style. “An architectural style is a coordinated set of architectural constraints that has been given a name for ease of reference.¹” In other words, by restricting the universe of possible design approaches an architectural style becomes a way of talking about architectural designs. An architecural design, then, is the blueprint of a running system. And an architecture is the system itself. Typically, as I do here, the latter two terms are conflated so that an architecure is an architectural design. By loose analogy, Art Deco is an architectural style, the plans for the Chrysler Building are an architecural design, and the Chrysler Building itself is an architecture.

The most commonly applied architecural style used in NOC systems is Representational State Transfer (REST). REST is a style that has the resource as it’s key abstraction, where a resource is anything important enough to name. A resource has state that changes over time, and clients interact with the resource via a uniform interface. Critically, resources also point to other related or interesting resources. REST as an architecural style is one step removed from an architecture. One possible implementation of the REST style is the resource-oriented architecture (ROA). ROA is the set of best practices encouraging the principled use of HTTP to create RESTful systems.

As regards NIC designs (e.g. CORBA, DCOM, and WS-*) there is no identified architecural style. Such architectures have evolved over time to address the needs of their creators and users, and later systems are typically modeled after earlier systems. Even so, it is possible to infer certain fine-grained styles inherent in these architecures, such as distributed objects or client server. One thing such systems have in common is the promotion of the interface as the key abstraction, where the interface describes a collection of non-unifrom operations/methods exposed by a service. Collectively, we can refer to these systems as having a service-oriented architecture (SOA).

In my earlier post I claimed that while governance and business process analysis are selfevidently important, that SOA (and ROA) did not exhibit sufficient uniqueness from traitional application design and development to warrant specialized versions of these. I’m backing off that stance. After all, if devolving a network-accessible application into its constituent components can justify not one but six distinct concepts, then certainly the same is true for governance and business analysis. In addition, NCC is indeed different enough that it requires a level and style of governance that needs to be clearly spelled out and executed. Ditto business analysis. I firmly reject, however, the idea that governance and/or analysis equal architecture and that the technology is not important.

As pertains to governance, ROA and SOA are different enough from each other that the policies and processes that govern them should also be distinct. Hence we’ll give them the simple terms ROA governance and SOA governance. But while the governance processes will be different, the governance needs will often be the same. For instance, either architecture could benefit from a directory. In today’s SOA environments that typically means UDDI. While in a ROA environment it is likely a Web page or simply the result of a search. (Or vice-versa.) Therefore, the common governance abstractions (directories, repositories, documentation, etc.) are given the term network-centric governance.

Regarding business process analysis, I don’t think that ROA and SOA warrant specialized techniques (but I’m willing to be convinced otherwise), thus we have simply networked business process analysis.

Summarizing the above taxonomically gives us:

– Network-centric computing (NCC)
—– Network-oriented computing (NOC)
——– REST
———– ROA
—–Network-independent computing (NIC)
——– SOA
– Network-centric governance
—– SOA governance
—– ROA governance
– Networked business process analysis

(I would have used nested unordered lists, but WordPress keeps horking that up.)

To use these terms in discussion we might have the following:An enterprise that recognizes that application silos are to be avoided and exposes functionality directly on the network for general consumption in a standardized and interoperable manner is undertaking a network-centric computing initiative (an NCC initiative). They may choose to acknowledge that the network imposes certain architectural constraints on this initiative and thus choose a network-oriented computing approach. This would be especially likely whenever crossing network boundaries, but is considered by some to be a good approach to most NCC designs. Alternately, they may choose to abstract the network away by using a network-independent computing approach. This is especially likely when the clients and services are on a single, well managed, local area network.