A comment that I left on James' blog awhile back has kept me thinking on the topic of web content management (WCM) and its relationship with enterprise content management (ECM). Others will surely disagree, but I think ECM as a meme just about owes its existence to its subsumation of the WCM domain, however tenuous that is/was. In fact, it seemed like WCM had barely gained its foothold, and along comes ECM knocking it to the side - score 1 for the ECM meme wonks.
Large enterprises had the notion of traditional document management (DM) well embedded, where things like workflow and records management excel. But the outlier was always web content management - that curious mix of kind-of structured content, very tied to it's distribution mechanism. WCM boasted it's own market segment and product portfolio, but its no surprise that to fulfill their destinies, DM vendors had to step up.
But how well has that gone? Tenuous at best, I would say. It's one thing to fill out a portfolio with acquisitions and update the PPT deck. It's another thing to deliver on the promise of unified content management.
Have the ECM vendors really won over the original leaders in web domain - the web designers? When was the last time you heard a web design team stoked about the latest ECM platform? The fact is that WCM product integration seems to be largely about foisting DM concepts onto the web domain, rather than building in the value-add features that web designers and developers need. (Note: this is really a retrofit value-add, as they have these features outside the ECM world - they lose them on moving day.)
There is a paradigmatic gap between the non-ECM world of web content management and publishing, and the ECM world. Web designers spend most of the early phases of adoption trying to shed baggage that will burden them down in the ECM world, and trying to un-learn all of the techiniques they had previously used to templatize sites (thing like server-side includes, iframes, etc.) They often need to port these same concepts to a new implementation that is ECM-friendly, to gain the "benefits" of enterprise quality. And have you heard a web designer brag about how great it is to change HTML templates in their favorite ECM tool? Templating is a whole topic on its own.
The nature of web content means that many ECM (nee DM) concepts do not apply. The world of DM is organized around a single artifact - the document. Sure, you manage relationships, but they are secondary to the artifact, and often relate more to packaging a group of artifacts for management reasons. The world of WCM demands that you manage related assets for distribution reasons - a subtle but important distinction. Web content is all about interrelationships - linking, styles, etc.
A bow to the vendords - it's no small task to try to productize the WCM domain. The fact is that there is a great continuum of web sites and web content. You will not have the same requirements nor solution for a simple, static brochure-ware web site that you will have for a dynamic, personalized information portal. A tool that works well for one will likely not work well for the other, which is a fly in the ointment for the E in ECM.
But that notion itself is predicated on the flaw in typical enterprise thinking - that centralization is automatically a Good Thing. The ECM sell often has something to do with single-sourcing. When there is a business case behind single-sourcing, it is a huge boon. But without a business case, it's an enterprise boondoggle.
Many WCM vendors or offerings try to growup to be ECM, but don't catch up with compliance oriented features. Compliance is critical to many businesses, but there are often process solutions and bolt-ons that can address that - I say hold the course on WCM. There is no shame doing what you do, and doing it well! Tony notes that everyone has to compare themselves to Vignette... I say be yourself.
A follow up on my previous post, but this one with a slightly more positive bent. ;-)
Here are a few of the architecture and development podcasts that I have found useful lately:
- The Massachusetts Technology Leadership Council Open Source SIG has a great podcast on Open Source in the Enterprise. I have only listened to part 2 so far but there is some great discussion around governance and comparison of companies with different cultures and different approaches to evaluation and adoption.
- IT Conversations has an interesting talk by Kent Beck on developer testing. Kent has a very relaxing tone and conversational style - almost hypnotic. (I listened to this while running the other day. I hadn't run in a very long while, and pushed my 3 mile target into a 5 mile - I thank Kent for putting me into a trance.) He has some good thoughts around thinking in terms of code health rather than quality or coverage and the traditional terms. Code health is the ability to respond to change - a good perspective on ultimately why you should write tests.
- PC Talk Radio - "Entering the Participation Age". This interview is a rehash / expansion of the talk that Simon Phipps, Chief Open Source Officer at Sun, gave at the Colorado Software Summit last fall. Phipps is a great conversationalist and lays out the interaction framework business models for what it means to have a commons that is built upon by contribution. Good stuff.
- Redmonk episode 1 was overdue - these will be great podcasts. I'm marginally interested in the Writely acquisition, but these guys are a great listen. I see that Episode 2 is already up - nice job, guys!
- On a related note, I have been working my way through various Drunk and Retired podcasts. If you like your tech content strong and straight up, then I suggest you look elsewhere. But I think these are definitely entertaining - Charles and Cote are a couple of bright guys talking software along with zombies and elves (you'll have to listen to understand). This is the sort of thing I have wanted to do for awhile, but is on the list of probably won't get to it - a morning talk radio-style technology show.
- I understand from Richard that the Ajaxian podcasts are a good listen, but haven't grabbed any of those yet.
- Speaking of Richard, Burton Group has started some podcasting, which seem to be in the brief overview segment - refreshing. I just noticed they have one on Skype, which I just got on this week - have to check that out.
Let me know if you have any decent podcasts to suggest...
I actually dislike the term blogosphere, but it is an unavoidably convenient term to capture a variety of things related to public conversations. I have been blogging for several months now, and thought I would share random thoughts.
The Wanderers
I have had some amusing visits from searchers - I'm sure these positions have changed, but here is what I was when I saw them come through:
- Second hit for an MSN search on "scott fertilize". I have a feeling this person was looking for a lawn product... unfortunately all they got was ramblings about EA, but would probably be just as helpful (if not more) for their original intent. ;-)
- Hit number 5 for a Google search on "Management" + "ivory tower syndrome". Trust me - it's because I'm cynical, not because I have it (have blogged to prove it).
- Second hit for a Google search on "strangler pattern" - I feel kind of bad, like I stole this spot from Martin and Mike, who got me started on that idea...
- Hit number 7 for an MSN search on "content tagging aggregation"
- Hit number 4 for a Google search on "gut and replace refresh cycle" - I kind of like that one.
- Hit number 10 for a Google India search on "mashup architecture".
- Hit number 21 for a search on "great architects" from Google South Africa!! Not sure what to make of that...
- Hit number 21 for a Google Blog Search on "social software in the enterprise"
- Hit number 13 for a Google search on "difference between application architect enterprise architect job" Probably a disappointed visitor... I don't think I'm helping clarify that at all.
- Hit number 3 for a Google search on "leadership resume points"
- Hit number 5 for a Google Blog search on "coaching youth baseball" (I noticed that I was a couple spots behind a post entitled "Confessions of a Bad Christian" - I thought the Vatican cleared youth sports under JP II ?)
My Friend Blogger
I am glad to see that IE hits on my site are down to around 25% - the lame Blogger templates have a IE bug that cause the right nav text to get hosed up, and I'm too lazy (and not HTML savvy enough) to fix it. But a friend is giving me hints.
This is my first blog, and I chose Blogger just because it was easy, but it's missing some pretty basic things that would make it way better.
- Why do I need to use HaloScan just to get trackbacks? Trackbacks seem fundamental to blogging IMHO.
- Why not have categories? (not that I really want to spend time categorizing my posts... I have thought off and on about starting to use Technorati tags, but just haven't started - I supposed that would pay better dividends that categories local to my blog.)
- Why the display bugs in the OOTB templates?
- Why freak people out on the comment form with the default "login to Blogger"? The simple forms from TypePad, etc. seem to encourage commenting...
The Problem With Public Conversations
Generally, why does Roller seem to be the only blogging platform that let's you subscribe via email to be notified on updates to conversations that you participate in? One of the worst parts procedurally of blogging in my opinion, is trying to keep up with conversations you participate - but it's really the most valuable aspect. Maybe I would get overloaded if all of the platforms had that, but I still appreciate the occassional email update on old comment threads from Matt's blog. Cocomment is a cool idea and might help, but seems to be experiencing integration woes, and I always forget to use it when dropping a quick comment. So for now I mark posts keep new in Bloglines and check back periodically. I would appreciate any suggestions on this.
Podcasts
I am going to bite the bullet and replace my toy MP3 player sometime this year with something that actually has capacity - but where are the podcast-friendly features? What do you mean I can't reliably bookmark MP3s - how lame is that? Sure I am an eMusic addict at this point, but the fact is that I use my player for podcasts more than music at the moment. I can't belive I can't reliably bookmark in Winamp, either... If you have a suggestion on a podcast-friendly large (20GB+) player, please share. I feel like there are many blog-style features that could be rolled into desktop media players (adding footnote style hyperlinks, bookmarking segments for note taking) but aren't - don't know why someone hasn't come up with a meta-data / XML solution for those.
Stop the Clock
Blogging has proven to be a time commitment. I suppose if I just shot out brief posts and didn't ever create that Bloglines account, it wouldn't take quite as much effort. But the gains for me have been the exchange of ideas and making some great contacts, both of which require a time investment. I seriously wonder how some peole crank out posts - between trying to keep up at my day job, working some side efforts (writing mainly), and spending time with the family, I'm thinking I need a 26-hour day to keep doing this! But I will keep at it, because I'm learning constantly, doing better at my job because of it - and it's fun.
A big thanks to those on my blogroll, and to those who have me on theirs - it's been a fun ride and it's not over.
Dave Nicolette offered up some phenomenal thoughts in a comment here on the enterprise Agile discussion that Cote' started. I thought these were worth re-posting at least for the benefit of the aggregator readers who don't check back for comments.... my thoughts below.
>I'm thinking what you actually had was a single point of representation
Right. "Customer" is a role on the team; there's no implication that the solution will be used by exactly one individual. In Scrum it's called "Product Owner." It's often a single individual, but there's no reason it can't be more than one person depending on circumstances. In "pure" Agile projects the development team is supposed to be colocated with the customer(s). On projects like those, I've had direct access to anyone who was to become a user of the new solution. But that's certainly not always feasible.
It's ideal in one sense when your users are inside the enterprise because you have a (perhaps?) captive audience, and usually have much easier access to your user base than if you were building a commercial software product. I think co-location is definitely a challenge in enterprises, unless the teams are small and there is some kind of office space glut - not common in my experience. But your're right on that this makes a huge difference.
>The finances of enterprise IT are one of the most difficult aspects to manage [...] annual planning cycles that are difficult to merge with a business-responsive development approach...
I think there's a widespread myth in our industry that there's a one-size-fits-all approach to software development. Most IT organizations do at least a couple of different types of software development work. Why assume both types call for the same approach or methodology? One type is user-facing, tactical, vertical business application development. These are projects that have a short list of business goals, a fixed timeline, and an identifiable business customer. They're usually funded by the business unit that engages the IT department to do the work, and they're cost-justified on the basis of direct impact to the bottom line. That's where Agile methods like Scrum, Crystal, and XP really shine.
The other type of development initiative is more akin to product development than project work. Enterprise-scale services are built and maintained on an ongoing basis. Unlike project work, there's not really an end date and "customers" may be indirect. An example is enterprise SOA development and maintenance. This is likely to be an ongoing effort that has a predictable release schedule, is constrained more tightly by compliance requirements than a tactical app, is funded out of the IT base budget, and cost-justified on the basis of anticipated future savings on tactical projects that are expected to make use of the resulting enterprise facilities. This operation might cull reusable features from various business applications over time, as well, and fold them into the SOA. For this sort of work, a lean development approach is often more practical than a pure Agile approach. Methods like TPS, CMMI, or MSF Agile can apply very well.
Contributing to the general confusion about all this is the fact vendors and consultants tend to use the word "agile" to describe both Agile and lean development methods. Both are aimed at reducing unproductive procedural overhead, but the two are otherwise quite different, and they apply to different classes of problems. Many people say "agile" when what they're really thinking about is reducing wasteful process overhead, whether through Agile methods or otherwise.
This is an extremely keen differentiation between types of projects in an enterprise, and appropriate approaches. I wish I had come up with that paragraph ;-) I think you are correct that tactical projects and user interfaces lend themselves very naturally to Agile as compared to larger enterprise efforts. (I would add product line practices to your list of approaches.) I don't mean to sound like a one-size-fits-all thinker (who would sign up for that moniker?).
I would not call myself a methodologist, though I am very interested in methodology. Others will surely disagree, but for me Agile approaches represent more than anything a set of values. I think those values and, now getting more specific, some practices should be applicable across projects using a variety of formal methodologies. A key Agile principle is that teams set their own rules - I think teams should be allowed to pursue a project with the methodology of their choosing, and that might not be Agile, XP, etc. But I do think they would benefit from still using certain Agile practices.
And I will plead guilty to using the Agile term to liberally, especially regarding lean. If I sat down with a methodology therapist, I would probably learn that I am perhaps more of a lean proponent than an Agilist when it comes to fundamental beliefs. I have spoken with Mary Poppendieck on a few occassions, and appreciate a lot of her thinking. Having said that, I think individual Agile practices are again quite portable across various approaches.
>Agile support models...
In a way, you're making my point about the belief in a one-size-fits-all approach even by raising this issue. Why assume that just because the development teams use Agile methods that the support group must use Agile methods, too? That said, it can be valuable to apply selected Agile practices to production support activities. At our company, we find the XP practice of pair programming works very well in production support. Two brains are better than one, and problems are solved faster. In addition, when two people work a problem together we end up with two individuals knowledgeable about the problem, for future reference. All good.
When supporting applications that were originally built using Agile methods, the support staff has the added advantage of a working, comprehensive test suite. They can run the test suite before making any modifications to code. That way, they can tell whether they are working from a clean starting point. If they write tests for all the changes they make in fixing the problem, then the test suite remains comprehensive and useful for future support issues and for future enhancement projects.
Often, production support teams work down a list of known problems and requested enhancements when they're not occupied with fire-fighting. They can apply Agile methods in that portion of their work, to gain the same sort of professional satisfaction and the same sort of good results as their colleagues in the development area.
I think you made this point better than I did, but you are saying what I was trying to get at. The fact is that support is not a project, and many of the formal methodologies are oriented around running projects. I think a phrase like Agile Support is intended to indicate that you are applying Agile principles and practices to the support process. You mention some good practices that apply - pairing, TDD. One point I was making is that I just haven't seen any flesh out a model around applying these practices to support because so much of the conversation is around running development projects - but this is an area of prime concern generally speaking within large enterprises, and I think they would benefit from applying Agile practices - lean approaches - to support.
Thanks for the fantastic comments, Dave, and taking the time to contribute here. I will be subscribing to your blog and look forward to your influence on my thinking.
Cote' offers up some notes on the practice of Agile techniques at large enterprises, and asks some good questions. I thought I would offer my take here...
Products
What product have you ever built that had 1 customer? :-) I'm thinking what you actually had was a single point of representation - and yes that is still a factor in enterprises. The key value at work is customer input - on a frequent basis with very open lines of communication. In our experience, a business analyst or user interface designer helps garden the input; we also hold frequent group meetings with users (more frequent than waterfall, less frequent than purist XP).
The Scrum-of-Scrums Needs Work
This is definitely a difficult point in enterprises, especially because groups are at very different places on the Agile learning/practicing curve (forget the same iteration cycle!), if they are on the curve at all. But I think many other groups appreciate the fact that Agile teams do things like include them as much or as little as they want, communicate with them frequently (rather than dropping a Gantt chart on them 6 months in advance and forgetting to tell them when the rest of the team slips), and give them short but reasonable notice on when to get things done. Yes, the last point is correct - I think a lot of the teams that are just staying afloat with operational activity don't do well with huge amounts of advance notice. Working short cycles and smaller tasks fits in better with operations.
Sales and Marketing
The finances of enterprise IT are one of the most difficult aspects to manage when practicing Agile, IMHO. Many enterprises have annual planning cycles that are difficult to merge with a business-responsive development approach, where you don't always know what it will cost up front. So I think the answer here is zone defense - you do what you can to stay traditional for these ceremonial activities, trying to carve out enough room to breathe. I think the proof is in the pudding - you need to demonstrate a lot of success with Agile before these behaviors will change.
Support
Agile support models are the final confrontation in an enterprise. A goal of Agile is to reduce waste in the process, waste here being ceremonial or overhead activities that do not directly add value. Contrast that with compliance needs in an operational environment, and you have some interesting forces on your hands. I think you are right that you can certainly apply the same principles, but where is the actual framework? It's too fun and cool to talk about development - none of these wonks want to flesh out an Agile support approach. Maybe we should make sure James tackles that in his coming book (again, I'm plugging you for info, James)?
Enterprise Installs Every 2 Weeks?
You had to say installs, didn't you? I choose to interpret the working-system-at-the-end-of-iteration mantra so it suits my needs. I think what you really need is usable system somewhere - preferable an integration environment - at the end of every iteration, with Production schedules less frequent, but frequent enough to be aggressively useful. The idea behind continuous delivery in my view is to ensure that integration happens sooner rather than later, to make sure the implementation stays integration-friendly (is on people's minds while coding), and to close the loop with customers. On the last point - that means both ensuring that what you did is correct, but also to let them play around before prioritizing your next amount of work... part of the maximizing the amount of work not done principle ("oh, we can just do it that way? well, let's forget about that other idea, then...").
Sure there is hype in the Agile community, but I think a lot of that is not from is promoters, it's from recently-bitten practitioners. You have to dig an approach that gets people excited about their jobs again. But without being a dogmatist trying to apply Agile to how you fill the coffee filter, there are no doubt ways to solve some long standing enterprise IT practices that are low value.
Scoble, James McGovern, Robert McIlree, Charles Betz and others have blogged on what is on their coffee table as far as reading material... thought I would do the same. Scoble wrote a quaint anecdote that a manager new to an organization just walked in and laid his current reading stack on the conference table as a means to let people get to know him - true you can learn a lot about someone through their reading list, but I think you learn a lot more from their comments on what's on that list. Perhaps you can also learn something about the books someone is selling off their table?
Recommended Architecture Reading
- Succeeding with Open Source
- I have only browsed this so far, but it comes highly recommended from a friend and is on my short list.
- The Practical Guide to Enterprise Architecture - Whose EA bookshelf is complete without this? I actually thought one of the most refreshing things in this book was the fact that there is a chapter on usability - not many EAs have the sense (or perhaps cojones considering the peer pressure to be an uber-tech geek) to recognize that practice as part of Great Architecture.
Recommended Development Reading
- Java Performance and Scalability, Volume 1 - I have no idea why this isn't one of the most talked about Java books - if I believed in required reading, this would no doubt make the list. This is a concise and utterly practical book that, despite its size, bulges with practical examples and objective benchmarks to show how to tune, using a web server as a sample application. The examples might not hold up with more recent API changes, and might not apply to your problem, but it will change the way you write code - forever.
- Test Driven Development: By Example - this book is deceptively small - it is a detailed look at an example of TDD on a given problem. I'm in the middle of this now... I find it too basic if you are already doing TDD, but might be more interesting if you are new to it. Beck has a great writing style - I think I might have enjoyed this book more.
- JUnit Recipes : Practical Methods for Programmer Testing - this book is full of great examples on ways to test; true to the title they are practical. They are the things you will soon run into on enterprise applications once you start testing, and are great suggestions. You should read this shortly after you get comfortable with the basics of TDD.
Recommended Business Reading
- The World Is Flat: A Brief History of the Twenty-first Century - So he's a cheerleader for globalism throughout the book, but I still think this is a great read. He's got great analysis of trends in outsourcing, offshoring, etc. and this will make you think about your job differently. I really think everyone should at least read the chapters on the Middle East at the end - very insightful.
- How to Be a Star at Work : 9 Breakthrough Strategies You Need to Succeed - OK, I actually just read chapter 6 "Knowing Who Knows: Plugging into the Knowledge Network" based on the advice of my then-boss, but I thought it was brilliant, and has had a lasting impact on my thinking around building a social network. I wonder if the rest of the book was that good?
Recommended Other Reading
To Do List
I have the disease of reading several books at any one time, putting them down, picking them up again weeks later, getting a notice from the library that a hold request came through and dropping everything to read that title before returning it... so this is really a portion of what is open on a desk somewhere in my life, or has dog-eared pages (there are at least a dozen dog-eared references in this book that I read last fall I still haven't followed up on.)
I have also provided review feedback on manuscripts and works in progress in the past, and LOVE it. I swear I prioritize that to the top of my reading list - drop me a line if you need a reviewer for an Enterprise Application Architecture or Enterprise Development title.
