A recent article on EA in IEEE Software has been generating some buzz in the blog space. The article was written by an architect at Martin Fowler's ThoughtWorks who contends that architects must "join the team" lest they become Ivory Tower dwellers. Jim Webber weighed in with his thoughts on the Ivory Tower of Enterprise Architecture, and James McGovern blasted the author, saying EA was way undervalued.
I was at first really caught up with the author's contention and inclined to agree, but I'm pulling back. James McGovern's brief comments re-oriented me... I think the differentiator is enterprise versus application architecture. There really is a lot of value in EA at the highest levels. Things like procurement and portfolio management are really best handled at the enterprise level, whereas I think the original author's comments were perhaps more directed at application architecture concerns.
When you start to get into the area of setting development and security implementation standards, or best practices for implementing a COTS package, then I think the author's contention starts to take off. Application architects responsible for monitoring those concerns in an enterprise definitely need to be team participants, or their advice exists in a vacuum. App archs are perhaps the most vulnerable to Ivory Tower syndrome... the poor ones try to distance themselves from development as an attempt to create an artificial hierarchy.
But any Enterprise Architect who can code makes better decisions generally, and specifically will have more credibility when selling down in the enterprise. James McGovern blogged previously at ITToolbox on architects who can't code, but I can't find the post at the moment - here is another good one, though.
Successfully EAs who truly do enterprise-level architecture also use Agile techniques, and will no doubt benefit from some amount of direct engagement with implementation teams. Think of it like Intuit's "Follow me Home" program - you should see the high-level in action to be sure you are delivering business value.
Patterns get a lot of headlines as a best practice for ensuring quality systems, but I'm a much bigger believer in refactorings. I have spent a lot of time on patterns and there is no doubt that they have their place, but I think enterprises that practice Agile will have much greater success if they emphasize good refactorings over good patterns.
The fact is that patterns set the wrong tone - they get you thinking too much about what is perfect, and not enough about what works and is practical. Talking patterns awakens the purist, and before you know it the sun has gone down and you are still at an impasse whether what are you doing should really be an Adapter or not.
Pattern purists will argue, but I contend that patterns are often out of reach for starting developers. Pattern culture is an extension of academic culture, where you are taught that there are experts and non-experts, and you know where you stand. Patterns emphasize that there is a right way, and you might get it wrong if you don't know what you are doing.
A refactoring-oriented approach, on the other hand, is steeped in Agile practices and encourages you to get something testable in place - delivering value instead of well-argued drawings. A culture built on refactoring also presupposes automated testing which is an essential practice for building quality systems. A refactoring culture encourages experimentation and innovation, and is much more easily accessible to entry-level developers.
Most importantly, a refactoring culture encourages you to deliver and gets you out of the head game of patterns...
If you are not familiar with the long and sordid history of intellectual property and copyright, you need to check out Free Culture by Lawrence Lessig. Lessig has some outstanding examples from history that parallel issues happening in the P2P and recording industry worlds today, and makes a great case for why IP laws need changing.
The software industry has had a mixed experience with IP. Of course, Richard Stallman got a lot of things going in the right direction with FSF. But the unsavory fact is that license proliferation is starting to clog the pipes for wide open source adoption. Why is it that most books on open source have to have an entire chapter dedicated to reviewing different types of licenses, rather than types of uses that could be covered by a single licensing model?
This is where Lessig's brainchild in the Creative Commons really takes off. The Creative Commons credo fully respects copyright and authors rights to work, but makes it far easier for creators to indicate their preferences, and for consumers to understand what they can and can't do. This is sorely needed in software licensing, where enterprise employees need to become license and IP experts to understand which frameworks they can integrate in internal projects. (How many of you know which license the Spring framework uses versus WebWork? Or, more importantly, what that means?)
I asked Simon Phipps, the Chief Open Source Officer for Sun, a question about Creative Commons at the Colorado Software Summit recently. Phipps completely gets the licensing issue, and has started a large effort at Sun to retire old licenses. Phipps also has the goal of creating a Creative Commons-style wizard for easily creating standardized and easy to use licenses for sofware - how cool would that be?
This is also important in the publishing and blog space - how many of you bloggers have considered licenses for your blog content? Are you concerned about how your IP is used? Have you thought about making it easier and legal for people to create derivative works? Take a minute for a good cause...
We recently brought Burton Group analyst Richard Monson-Haefel in-house for a discussion on what Burton is calling the "Rebel Frameworks". For us, this was a discussion on best practices and principles for evaluating more lightweight open source tools and frameworks so that we can be more architecturally Agile.
Richard has some interesting perspectives on this issue... he founded the MockEJB project, and authored 2 best-selling O'Reilly books on EJB and Java Web Services - you would think he is a big standards wonk, but guess again. Like many pundits who spent years under the mind cloak that EJB was a Good Thing, he is now extolling the virues of Ruby (along with people like David Geary, who wrote previously sang praises of JSF and JSP). It should give all enterprise architects pause when some seriously bright people are willing to walk away from what they have been saying for years, and admit they were wrong. Are standards so great when tons of doorstop-quality books are required to explain them, and their apologists even stop apologizing?
Being a fan of simplicity, I propose a very simple litmus test that can help with extremely quick assessment of API and frameworks. This simple test involves asking yourself honestly, if this approach seems ridiculously complex or whether it genuinely helps you get there faster. Think about your first Tomcat download and startup - definitely simple and quick. Now try it with JSF - ridiculously complex. Think about where portal technology was a couple years ago when it just hit the hype list - ridiculously complex (arguably only slightly better today, but getting there - smart enterprises are second-guessing vendors who sell it as a chainsaw that can cut butter, but that's another post). How about insert the name of the last large commercial offering your company procured here: ____ is ridiculously complex. Did that sound natural? Did that purchase really jettison your team down the delivery path? Or did you spend time negotiating it into your physical architecture, and trying to get high-paid professional services teams back in town to help you decipher log messages?
Large enterprises are usually skittish about open source - there is a PowerPoint-style comfort level to have a contract filed away somewhere. Some folks with 3 letters after their names think it's nice to be able to assign responsibility to people on the other end of the phone, even if they are in India and you need to work through 3 levels to get to the person who now maintains the code (the one who wrote it was outsourced). But what about maintaining control and ownership? What about the fact that many open source projects have as good or better customer service models than commercial vendors? I think every enterprise, especially large enterprises, have an obligation to explore and support these offerings. It might not get you a free lunch, but then again might make sure you have time for lunch...
Many architects spend a lot of their time on technology - hardware and software components, frameworks, SOA, etc. But Great Architects are equally as concerned with people and processes.
Awhile back I was inspired by James McGovern's thoughts on bringing the conference to you. We have embraced this idea, and are currently in the middle of an extended set of training sessions for our entire development team. A couple months back, we brought in a local consultant (Mike Calvo, who I would highly recommend to anyone in the Minneapolis area) to run the team through a reference project using JSF, Spring, and Hibernate. This was a great chance for our team to get a complete look at all of those technologies together, and see a working, running app. Mike had just come off of a large ecommerce project using these, so he had great practical insights that are too often lacking from more formal training classes.
Our next session was with a lead in our internal DBA group. He gave us a list of possible topics that we prioritized, and then gave us a half-day run through of tips and best practices on those topics. No doubt this was review for some of our team members, but most of the team thought this was great exposure to best practices that are normally ignored (this being a bunch of Javaholics).
The remaining planned session is with Richard Monson-Haefel, a Burton Group analyst. You might know Richard from his fantastic O'Reilly books, but he is also one of the only working industry analysts giving airtime to open source in a meaningful way. If your company is not a Burton Group client, I suggest you check them out.
We are still trying to round out our sessions for the year - thinking about topics in the Agile or test-driven development areas. But overall, this has been a great experience to get our entire team talking the same language, and has definitely increased healthy discussion and debate about frameworks, tools, approaches, etc. that we are considering.
I'm curious to hear what other architects out there are doing to build people as well as technology assets in their enterprise...
