Perhaps the label might be helpful in providing the shared understanding of Enterprise. I’ve read references to internal software built by internal teams for internal users, proprietary software built by external teams and sold to consumers, and more. To me, those are delivery mechanisms, not the diagnostic.
When I hear the term Enterprise used, I believe it’s in reference to solutions having a direct relationship with someone’s job. With that, Enterprise can be a label used to describe systems used to satisfy the needs of a job. That can be anything from SAP to Facebook, as long as it’s being used to meet those needs.
I also believe Enterprise design is facilitating relationships between multiple systems, organizations relying on these systems, and users. CRM, Learning Management, Workforce Management, Knowledge Management, Performance Management, Multi-channel, Voice of the Customer, etc. are examples of these types of systems. Each example could, by itself, be a rather ‘large’ system with scale, wickedness, and proximity issues. If you consider the daily interactions of an Enterprise user (someone using a solution for their job), one has to understand they are traversing in and out of these systems for any given process.
To reiterate on what Dave mentioned above, the practice of design for Enterprise may differ from that of many consumer products because of these relationships between systems. Designers need to be aware of these relationships, or dimensions as Jared wrote. That doesn’t make the practice more difficult, but many designers don’t deal with these specific dimensions on a day to day basis, so it’s different. There is less literature about the dimensions, so I believe this discussion is about exactly that.
Similar to a consumer context, Enterprise users are constantly looking for alternatives. They have simple, "easy-to-use” solutions in other areas of their lives and are looking to incorporate these types of solutions into their professional lives. Many users take matters into their own hands, finding and using alternative solutions which fly under the IT radar. Eventually, many of those solutions are discovered and shut down; largely due to security and stability concerns. I see this as a massive opportunity lost for organizations. Instead of listening and discovering why users have sought other solutions, many orgs simply make these solutions go away. This is where the practice of design can play a major role.
All that said, my practice of design in an enterprise context means I work directly with business and technology counterparts on a daily basis. What I mean by that is, in order to incorporate design into the end-to-end process, I have to understand the languages my colleagues speak and in turn, be able to communicate design in those languages. For me, this has provided a lot of exposure to many areas I don’t believe I would be exposed to otherwise. I work daily with teams from Legal, Finance, Procurement, Business Strategy, Operations, Public Relations, IT, etc. This has proved to be invaluable, as it affords me constant opportunities to incorporate design approaches into different areas of the business. It’s not special, it’s not harder, the context is just different.