Fortunately, the tips below can make the process far
simpler than you may have believed.

I’m sure that’s a problem that can be solved — needs to be solved, in fact — but again, it’s very different from the startup/web world, and I think it’s one reason that the Big Design Up Front has such staying power in the enterprise, even though it’s almost always wrong: the BDUF at least ensures that you start out with a lot of resources, which you can later reshuffle as the architecture evolves.

My mandate was basically to avoid building anything locally if you can, but if you did then the guidance from the high priests was a bit or miss. In one case they insisted using an Model Driven Development approach complete with ESB for a simple ETL problem. That turned out to be a bit of a train wreck (drawing software instead of writing it has never turned out well for me) and it ended up being a franken-architecture that will live on as my legacy unfortunately (sorry guys!). On other occasions we were able to do things really well because of the organisations ability to focus investment (they have a great reporting solution used across multiple lines of business).

To answer your question, yes I agree this is a difficult thing to get your head around as an enterprise and I am surprised how well it works sometimes to be honest. In terms of a practical approach I like what Neal Ford has been saying about evolutionary architecture (http://www.ibm.com/developerworks/library/j-eaed1/), but I think the tricky part is spotting the accidental complexity when you are flying at low oxygen levels.

“The benefit of all this mess, though, is that an enterprise application designer is always thinking about distributed data, something that web developers talk about don’t always really get. It’s hard to imagine a CMS like Drupal or WordPress — that naively assumes it can keep all the information that it presents in its own (preferably MySQL) database — coming out of the enterprise.”

So basically, I’m saying (again, overgeneralizing) that web developers are completely clueless about data and integration.

Good: Up to date on the latest tech. Passionate about technology.

Bad: Get bored if things don’t work in the first 30 minutes. Have no idea what would happen to their business if all their clients’ credit card numbers were pilfered by a SQL Injection attack. Or don’t have a business because they’d rather make it look cool than provide actual value.

The above doesn’t apply to everyone of course, but the article appears biased, especially as it starts off with claims to have straddled the fence and therefore bring a balanced viewpoint.

In principle, the portfolio of apps is the responsibility of the Enterprise Architect, but I fear that the enterprise-architecture field isn’t really getting a practical grip on it yet (other than drawing diagrams and trademarking new process names). What have you observed?

One thing I would add is that while there is a lot of focus on getting maximum efficiencies out of the devs, there isn’t as strong portfolio management. We are good at building stuff predictably, but is it the right thing to be building? It is exacerbated with the project funding process which starts mid-year. You effectively are asking $x for a project that won’t start until 15 months away. Can you really quantify the value and effort for something that far out?

One idea I’ve heard of that I’d love to experiment with, is to have cross functional teams lobby for funding much as a start-up would pitch to an Angel investor. Projects would be funded based on a business case, but only enough to get to MVP and you have to be able to demonstrate value in 3 months max. Kind of a lean intrapreneur model.

Unfortunately, I’ll never get the chance to experiment because I have resigned to go back to a startup…

Actually, it passes blanket judgement on two entire tiers of developers. It’s just as harsh on web devs as it is on enterprise devs, though the web devs haven’t been the ones reacting in comments (probably because they haven’t discovered the posting).

Perhaps some more perspective would be helpful. I’m writing this from the POV of an architect designing systems. While I deal with individual developers, I can’t design for them individually, because developers change jobs; instead, I have to design for the organisation. That means that I have to have a mental model of the kinds of people who will be building, maintaining, and operating the system.

With that in mind, I have to design for a hypothetical average developer in both camps. Of course, averages are unfair to individuals — someone (I’m too lazy to look it up) once wrote that the “average” person has one breast and one testicle — but over and over again, I’ve found that I have to adjust my designs for the two worlds to avoid disaster:

• Web developers work faster, know lots of tech, and take a lot of initiative. For a specific coding task, I typically assume an “average” web dev will work about 10 times as fast as an “average” enterprise dev, produce better code, and have a much-larger IT skill set. They can change a system quickly if it’s not working, and they’re happy working with incomplete requirements, so the initial release can go up faster — for a web dev, every release is just a step towards the next one.
• Enterprise developers are better team players, consult more, and communicate better. I typically assume that the “average” enterprise dev knows how to coordinate with other teams, understands the importance of shared artefacts (whether requirements docs, UML diagrams or Agile stories), and gets that there’s more to software development than just coding (product management, documentation, sustainability, etc.). They need a more-stable product to work with, but once they have it, they’ll keep it running, and will make sure that it works with everyone else’s systems, too.

Two different kinds of audiences == two different kinds of design. Of course, there are many individual web devs who are good communicators, and many individual enterprise devs who are hotshot coders, but when I’m designing a system that might be in use for 10+ years, I can’t design for the outliers.

“Of course, there are people like that in enterprise, too, but it’s hard for them to last, because the enterprise can really wear down your soul and make you hate coding.”

This may be your experience but that doesn’t make it everyone’s experience. Are you saying that non-enterprise devs never get worn down? Really? At best you can say this is a more common occurrence for developers in any large scale organization. That would be reasonable.

This article was clearly posted before being well thought out, and you’re paying the price in the comments section. You get kudos for encouraging the discussion.

Would be fantastic if this post took the occasion to look at the different focuses of the two camps and what each can learn from the other. As it reads, its simply passing blanket judgement on an entire tier of developers, which is patently unfair. If you’re going to back down from the generalizations, then stop making more of them. If you find yourself in a hole, stop digging.

The work-life balance issue that a few comments have brought up is also similar to what I wrote in the second half (though perhaps with too much condescension). The difference between a typical enterprise dev and a typical web dev is that the (stereotypical, overgeneralized) enterprise dev sees coding itself as work, while the (stereotypical, overgeneralized) does not. When this archetypal web dev gets home from “work”, she curls up with a new book on NodeJS instead of a spy novel, because that’s what she’s been looking forward to all day — that’s not work for her; it’s relaxation. Think of the airline pilot who rushes home on non-duty days to fly his Piper Cub instead of heading for the golf course — it’s the same idea.

Of course, there are people like that in enterprise, too, but it’s hard for them to last, because the enterprise can really wear down your soul and make you hate coding (simply because big organizations, public or private, have such a high transaction overhead). I’m at the end of deep involvement in a complex, high-visibility, 3+-year enterprise project right now, and it’s going to take a couple of months before I actually like coding again. At this moment, I more resemble the enterprise developer in my posting than I do the web developer.

Like jniehus said above, I choose to not work after hours or on into the night because I have a wife and two small kids and my life is not solely about being a developer. I am highly productive and get a lot done and don’t feel compelled to work until midnight jacked up on mountain dew hacking out the most awesomest code.

The bit about there not being any good developers in enterprise is an absurd generalization. There are A players here, but there are a lot of B and C players too. I find enterprise is slow to adopt bleeding edge technologies (we are only now getting away from IE7) and so the speed at which things move forward is slow. As a consequence enterprise developers are often not as interested in learning and self-educating in their craft. The B and C players more often come with a certain set of skills and never evolve. But you are mistaken if you don’t think there are A players in enterprise that are churning out great code and even better ideas.

Bottom line is the set of problems enterprise developers are solving are quite different, and it requires different focus. Some of us prefer the security of employment in a large, stable organization rather than the unsure nature of indie start ups and consumer oriented/social/e-commerce work.

Some day when i ride off into the sunset with my retirement account fully funded, I may develop independently, but that’s after the kids are through college and I have other arrangements for health care, etc. etc. Until then I am making good money being an A player in enterprise.

Way to keep the stereotype going…

Im only happy to leave at 5 because I have better things to do with my life, like play with the kids, read books, and complain on blogs.

Henry Ford figured out over 80 years ago that working more than 40 hours a week is a waste of time for the average person. Personally, its been my experience that I’ll figure out solutions to problems more often during “off hours” while doing something completely different then sitting around staring at a screen full of code.

If a “dedicated” and “passionate” engineer has to spend 12+ hours a day and work weekends to accomplish anything, that just tells me they fuck up a lot.

I think the challenge is the mind set in the enterprise which I’ve found to be more about synchronisation of duplicated data rather than querying over duplication.

Also cost. I guess a lot of companies are focused on their business, and will put into IT resources based on the short term gain in efficiencies, not that extra cost for a gain in long term scalability or maintainability.

I hate to tell you this but simply by the laws of statistics, most developers will be mediocre, no matter the company. They’re about 80% of the bell curve, so the idea that as an independent or as a start-up, you’re going to have all this unbridled passion and expertise that’s heads above enterprise development is going to be wrong 8 times out of ten.

Why doesn’t enterprise have many rock stars? What field is littered with rock stars? If there was an organization of nothing but rock stars, I haven’t seen it, and most likely it would be torn apart by big egos of hotshots who all think they know better. Again, that 80% of the bell curve is working against you…

One of the biggest things that enterprise offers is breadth. You may be working with everything from integrating with a mainframe, to writing RESTful services with JSON APIs means to manage data in a cloud you just built. And if you follow Agile and XP, odds are, you’ll get exposure to all of this in one form or another. Projects in which you get to rule your little fiefdom and write everything from scratch will not teach you this, so lets not bash the skill set of an enterprise consultant or full time dev because of the size of the teams.

PS: I often find that people who say that a certain group in the profession doesn’t get something, proceed to dismiss certain tools for integration (though you really dismissed communication protocols/formats, a design pattern, and a data warehousing process in the same breath with no differentiation) with no detail as to why they’re bad, rarely inspire confidence in their abilities. It’s one thing to have a different opinion about a complex topic, but here you didn’t even try.

As an independent, I’m neither a web dev or an enterprise dev, but I’ve spent about equal amounts of time working with each over the past 15 years. Most of the time, they really don’t get each-other’s worlds.

To overgeneralize again (both groups contain many exceptions), web devs complain that they can’t just use Rails and Mongo, release something simple next week, and sort out bugs later (not such a great idea if you’re the government or a big corp, and might leak 1M users’ personal information and credit cards, or generate $10M in incorrect purchase orders), and enterprise devs complain that there’s not an existing module in WebSphere or SharePoint to do the work for them (even when configuring and integrating that module might take 10x as long, with a higher sustainability burden, than simply writing, documenting, and maintaining a couple of hundred lines of custom code).