What is development in the "Enterprise" like?

Question

I am a CS student that knows his way around ASP.NET, MVC, Ruby On Rails, MS SQL, C#, Java and so on. I have also immersed myself in the ALT.NET community. Avid reader of Jeff and Joel, CodeBetter.com, Martin Fowler and so on.

A while ago I asked "Implications of Sharepoint, BizTalk, Microsoft Dynamics and Microsoft CRM for a .NET developer". I didn't get the answer I really wanted. But that doesn't really matter, as there are also a lot of non-MS "Enterprise" technologies around.

Sharepoint does not really concern me, but it is the whole of "Enterprise" technologies that have me worried. Big companies love to throw around a lot of terminology around like: SOA, DSL's, SAP, ERP, Dynamics, CRM, "Business enablers" and so on.

I attended an lecture by Capgemini on SOA. They did something with "Oracle SOA suite" to model service flows or something. Seems kind of similair what Biztalk does. Also there is a huge market for "SAP consultants". What does a SAP consultant do? Does he program? What does he do? What do "Dynamics" developers? What does an Oracle expert do?

In college we are working on a project using J2EE. A specialist from another company came by to tell something about the SEAM framework. I asked him how SEAM stacked up against Ruby on Rails and GRails.

He said "Seam is more mature, Rails and Grails are more suited for your soccer club.". Then he handed out, you guessed it, a booklet on SOA with Oracle tools.

I also watched some videos from a regional company specializing in Microsoft Enterprise. There was a video on the automation of an City government, all I could hear was Biztalk, Workflow, SOA, E-Office, back-office, mid-office and so on. There was no mention of what kind of data access pattern they used, or what kind of language they used, or stuff like that. "And then the building permit request is injected into the Sharepoint document library." Is that XML? Is that SQL? What do they mean by that? What did they "program"?

I would love to work on big applications that impact people's lives, but as the Django guy puts it, this all seems like "big and boring applications no-body cares about".

With all these terms being thrown around, it is very unclear to me what an Enterprise developer does on his day-job.

Things can be different though. Trough the national ALT.NET User group, I came to know a company located in an old farm in the woods. They listed things like "NHibernate" and "DDD" in their job descriptions. It genuinely seems more "Alternative" as opposed to the big Enterprisey companies. And I have much better idea on what they do.

My question now is this. What do Microsoft/SAP/Java/Oracle Enterprise developers do in their day-to-day jobs? As companies love to smack terminology around, it is difficult to see the trees trough the woods.

Answer 1

At a VERY large enterprise (think Fortune 100), you would likely be developing interfaces, reports, and modifications for software like Oracle or SAP. You would work with one of their various frameworks, but would only see a piece of it. For example, imagine working in RAILS, but only being responsible for a small subset of the model.

If you are a strong developer, and WANT to work in a corporate environment, I'd suggest looking at consulting positions. You'll position yourself well to become a high paid SAP/Oracle/etc specialist down the road, and it will look good on your resume. Otherwise, you'll likely be put in a cube working on report development in Oracle PL/SQL and wondering why you spent $100K on an education.

I took the consulting route myself for a while, and I rarely met an enterprise develop who liked their job. That said, they loved their home life, and left about 5 hours before us consulting scmucks. =)

Answer 2

What does an Enterprise developer do?

Look at the screen on your iPod Nano. Now, imagine building a 747 using only that size window. So, you never see the big picture.

As you progress you can really get good at screwing on the custom designed farfignewton bolts and everyone on the 747 team will know what that is and that like 3 people are good at it, but not a single person outside of your team will have a clue. So, you can't explain what you do and say, "I help build 747s"

Answer 3

Also there is a huge market for "SAP consultants". What does a SAP consultant do? Does he program? What does he do?

While there is a common joke that "you don't customize SAP to fit your business, you customize your business to fit SAP", there is a substantial demand for people who can customize SAP installations (to add functionality, make it talk to other systems, etc.). I suspect that it's not so much that the demand is "huge", but that the supply is very limited, since there are few opportunities for newcomers to gain real-life experience - everyone wants an experienced SAP consultant, but nobody wants to be the training ground where newbies could get that experience - not when the system in question runs your entire business.

It seems like you got to meet some pretty bad buzzword consultants; there certainly are many in the "Enterprise" market who are trying to make up for a lack of substantial expertise with extra buzzword- and Powerpoint-skills.

But on the other hand, "Enterprise" does mean that you constantly have to talk to non-technical people (management and domain experts) where it can be genuinely beneficial to avoid technical details - for many, that becomes a habit.

Answer 4

For me, 'enterprise' is conservative, slow-moving, potentially grandiose but with a large chance of slowing down your career to the point where you end up writing a .NET 2.0 application for three years after .NET 3.5 has been released - with an old version of Visual Studio to boot. The other comments here are fair too, in the sense that you might end up being 'pigeonholed' into doing part X of a suite of Y in a group of Z.

One upside is being able to use those 'heavy' technologies like BizTalk, Oracle, etc. - they do look good on a resume. But IMHO, the scope for creativity when working with an already existing framework is a lot less than when working with a brand-new, never-before-done application. Kind of like CMS vs. personal homepage.

Answer 5

I think Alex on The Daily WTF said it best:

'I most of us felt (or, will feel) let down after getting our first job of college. Going from the world of "assume there is an unlimited budget, now ..." to "change the text of the error message generated by ..." makes you feel as if your hard-earned Computer Science degree was as useful as Mordar, your almost-equally hard-earned level 28 half-elf wizard'

http://thedailywtf.com/Articles/Welcome_to_the_Real_World.aspx

Answer 6

As an Enterprise software developer, I view my job as automating the daily work of others. I work on an HR system for a government agency. If I've done my job well, 90% of an HR person's daily tasks are automated away into triviality, leaving them to spend the majority of their day focusing on the last 10% of their tasks.

The technology I use to accomplish this task is subordinate to the relationships I develop with my customers in the course of solving their problems and the domain knowledge I gain from helping them automate their pain away in an intelligent manner.

In my daily work, I excersize every phase of the software development process. I work with the analysts to hash out requirements. I design a solution, taking into account the larger system as a whole and the constraints of our existing platforms. I implement my solution, test it, and deploy it to production. Then its off to the next feature request or bug fix.

Developing software in the enterprise is different from product development at a full time software company. In my job, I have only one customer and it's my job to build them a software system that fits them like a glove. Whatever they want, they get. I do my best to advise them when what they're asking for is inherently wrong or can be significantly improved by changing the process. Sometimes I win that battle and sometimes I don't. As an enterprise developer, I don't have the luxury to buid my systems in the clouds of accademic and architectural purity. Sometimes I have to build things that I think are pretty stupid, in ways that make no sense, just because the customer adamantly wants it. In the end, it's their system and they are paying me to build it.

I use SharePoint, SQL Server, ASP.net, XML, web services, and a whole litany of alphabet soup to accomplish my work. An average enterprise developer can entrench themselves in one or two technologies and become an expert. The best enterprise developers are generalists who can integrate lots of systems and technoloties to get the job done.

Answer 7

Like others have said said, enterprise developers mainly work on relatively small pieces of large systems. Here's a list of bullet points that may help, mostly from my experience:

• You'll likely work for a boss who hasn't written a line of code in a few years, if at all. You'll develop in some language (C#, Java, whatever), work on one or two projects at a time on one or more internal systems, bang away on some over-designed interfaces, write some documentation, read a lot more documentation, and attend meetings. Day after day. For years.

• If you're good, you'll learn the ins and outs of some very specialized business systems (order processing, report generation, internal messaging). You'll spend a lot of time thinking of ways to make your projects work better within the confines of the rules and processes that you're given. You'll save the day a few times and royally screw up a few times. In Enterprise, the consequences are big.

• The projects you are responsible for will drag on for months or years. Regardless of your skill and motivation as a developer, your projects will most likely be late and/or over budget.

• You may theorize that some/all of your projects could be done with your college/online buddies in a fraction of the time, given the right tools and proper requirements. You'll probably be right.

• You will likely encounter many obviously flawed/wasteful systems and processes (even whole departments!) at each employer and may feel the need to speak up or even fix the problems. Don't. Enterprises don't want to be fixed because that involves risk which involves money. It also involves accountability. You'll understand after awhile.

• You may suddenly realize that many of the processes and rules in place are designed not to help you develop, but to hinder you. Management won't have a problem with this.

• You'll be able to sneak real change in the back door, but you have to be prepared and choose the moments carefully. The key is that once the business depends on it, it's good.

• You'll have to work with consultants and vendors from time to time, each of which can range from terrible/fraud to excellent/genius. They will get paid a lot more than you and you'll know it. Consultants will introduce new processes, while vendors will bring new systems, network protocols, and file formats.

• If you keep up with IT news online, you will already be aware of the benefits and risks of the new processes and technologies. Your boss will probably know less than you. His or her boss will know even less. The executive who authorizes the new process or technology won't understand any of it.

• Expect to be given new directives every few years about what silver bullet you are expected to learn and implement as part of your employer's "new direction." There will be a consultant or vendor behind this.

• The specialized knowledge that you acquire over the years will essentially be useless outside of your employer because the processes, systems, and schemas for which you have experience were tailored specifically for your employer. When you change employers, you will be given new instructions on how to proceed with development.

The reason you're having a hard time picturing all of this from the "enterprisey" company descriptions is that there is quite a bit of obfuscation going on on all levels of the business. Executives like buzzwords and acronyms, sales people speak that language with fluency, and no one but the developers really care what it all means. In fact, one of the consequences of this arrangement is that your experience from these types of jobs will give you a "pluggable module" type of appeal to other companies. The acronyms on your resume will literally define you as a developer in the eyes of future employers.

Oh, and the reason you're "building you resume" is to get another enterprise developer job or enter management.

That's not to say that you shouldn't pursue this career path. In fact, many developers thrive in this area and are able to build successful consultancies or enterprise vendors of their own. There is a ton of money in enterprise development, especially for specialized vendors.

Answer 8

I'm an enterprise architect, a job role that I somehow worked my way into after 15 years in the enterprise biz. I've never worked for product development; even my time at IBM, Dell, and Microsoft was spent on the enterprise side of things.

My primary focus in my current gig is on ensuring that our system runs smoothly and accurately so the services we provide to the citizens of this state are consistent, cost-effective, and most importantly, accurate.

I work with Sharepoint, SQL Server, .NET development in C#, Windows servers, virtualization, Windows Workflow, and a few other interesting technologies. My focus is on implementing IT governance concepts, as well as IT service management. My day-to-day tasks can include anything from meeting with management on Phase 3 of our project to fixing a bug in an ASP.NET page.

I guess the key for me is that all of my decisions, all of my work, is directed first at the program--the interdependent projects that make up our enterprise application portfolio--and then at the individual components that make up our projects, including people, code, technology management, and change.

I hope that makes sense.

Answer 9

I answered you last question, I will answer again. If you are starting out your career I will suggest you get rid of this insane focus on what enterprises do. From a developer perspective enterprises are probably the least desirable places in the known universe. Long winded processes, day long meetings and insane processes. Dilbert is the truth in enterprise.

I know this was hard for me when I was just finishing university. I simply knew so little. I even thought I could be a decent manager. Or a project manager. After a few years I realized I was at my best when I was making things, preferably beautiful things. So I did that. And today I work for enterprises, but stay in positions where I can get things done, send someone else to those meetings. No more monkey enterpise-participation for me.

Answer 10

Since you are just starting a new career, you'll need to learn to manage your time, be a team player and deal with "political stuff" to survive.

Here's a link to a free download of my e-Book "Enterprise Software without the BS": http://yakovfain.javadevelopersjournal.com/enterprise_software_without_the_bs_is_available_for_download.htm