I've been giving a lot of thought, lately, to enterprise coding standards, development policies, and so on. I've also been following the largely laughable marketing buzz that is "Enterprise Software". This Meditation is the result of pondering the pragmatic decisions I might make were I to be asked to set policies and standards for an organization.

Definition of "Enterprise Software"

Don't buy the media buzz: enterprise software doesn't mean "enterprisey". The term "enterprise software" has some merit, if thought about in some kind of sane context. Since the term has turned into some bastard child of marketing, I feel the need to clarify the term at the outset.

enterprise software
Software designed to serve the needs of, and be maintainable long term by, an organization rather than a specific development team.
Essentially, enterprise software is software designed and built by one team, with the intent that it will be maintained by a completely different team, possibly some years into the future.

Considerations

Enterprise development has three main components:

  1. Development standards
  2. Change control standards
  3. Documentation standards
These each bear discussion, but the latter two are in many ways obvious; and where they are not, they are highly subjective for a given organization. Let me expand these components briefly:

Development standards include choice of language, requirements for interacting with other code (e.g. libraries, IPC), vetting of technologies and modules, and choice of methodology. This is primarly what this meditation is about.

Change control standards deal with language and interpreter/compiler versions, library versions, source control systems, coding styles0, and deployment methods. In general, I support use of the most recent well-tested and stable versions, and the use of a good merging source control system (often CVS1).

Documentation standards address content and style of in-code comments, user and technical documents, documentation of third-party modules, publishing standards, and so on. I tend to recommend established best-practices for each chosen language -- e.g. use Javadoc for Java code, POD for Perl code.

I mostly want to focus on choices of language for this Meditation.

The Language Trilogy

Lots of managers think it would be great if there was a single language that was an ideal candidate for all enterprise software development. Such a thing doesn't exist, and I believe that it can't (and shouldn't if it could). So, a variety of languages is a necessity in most organizations. The question becomes "which ones?" Consider the requirements:
  1. Complete. An enterprise langauge needs to be, at least in theory, capable of expressing the solution to any class of computing problem. In other words, Turing-completeness is a good start. The ideal languages would have pre-built features that represent a broad range of solution spaces as well. Finally, complete languages have readily-available mechanisms to deal with current technologies (e.g. XML parsers, network support, database classes, etc.).
  2. Readily available. The language, its interpreter/compiler/SDK, its documentation, its class library, etc. need to be easily and relatively cheaply available to developers.
  3. Established. A chosen language should have a bit of history behind it, and have been tested reasonably well -- it's important to have confidence that the underlying system has as few bugs as possible. Additionally, the language should have a well-established community, and good availability of educational materials (books, and such). Perhaps most importantly, the language should have attracted a reasonable pool of skilled developers. This last will be essential when it comes time to hire replacement team members, or to engage maintainers in the future.
  4. Multi-platform. An enterprise language should be able to work across the enterprise: and that means it should be available on every platform that exists in the organization. It should be relatively easy to write cross-platform code, and just as easy to write platform-specific code where it's required (such as automation of administration tasks). This is probably the biggest challenge, as there are always niche platforms that pretty much require their own language environments (AS/400 and RPG are an excellent example). It's also the primary reason why a single langauge isn't appropriate, and why every sizable organization occasionally steps outside the chosen set of languages.
  5. Testable. Any enterprise language should have an existing testing framework that makes it relatively simple for developers to practice test-driven development and perform automated regression testing.
There are dozens of languages that fit the bill to some extent. While it's necessary to combine languages to achieve all the requirements, it's desirable to minimize the number of supported languages from a management point of view.

Most organizations of any size have some combination of UNIX-alikes (UNIX, Linux, BSD, etc.) and MS-Windows. And, they have a combination of web/server, desktop, and script environments2.

Java is immediately appealing: it meets all of the requirements to some degree, the framework itself costs nothing, and the available tools for web and desktop application development are excellent (think Eclipse {free} and RSA, not to mention Ant and the like). The spec for the language is open and a ratified standard. Sun is even moving toward open-sourcing the kit. Plenty of developers are available, and the nature of the language (and available tools) provide some measure of protection against mediocre developers.

Java, though, tends to be slow at runtime (well, mostly during startup). Besides that, it runs up against a wall when doing things in script environments. Yes, you can shoe-horn it, but it's not easy to write, say, Windows automation in Java. So, while Java is a good choice, it isn't a complete one.

Many organizations turn to the .NET framework to address their Windows needs. This is largely a result of an object model that makes Windows features available to developers in a way that a language like Java just isn't intended to. .NET languages satisfy most of the enterprise requirements, and their ability to rapidly solve Windows-specific problems is simply a requirement in most organizations. C#, while somewhat unweildy, is a good choice to complement Java -- the syntax and program structure are so close to Java that Java developers can often be retrained as C# developers in short order. This allows better management of a development staff, as you can have cross-functional teams allocated to whichever dev group is in need at the moment.

But, with C#.NET and Java, you still have rather large frameworks. And, while C#.NET works very well in Windows scripting environments, it doesn't do the job on other platforms. Add to that, both languages are horrible for the "quick one-off" applications that solve so many business problems in the typical organization.

Unfortunately, most organizations I've had the opportunity to work with can't see that shortcoming. They've standardized on the .NET and Java platforms, and when problems inevitably arise that don't fit the development model or capabilities of these systems, the dev team steps outside them. And, as a result, you wind up with a huge tangle of scripts in four different UNIX shells, the abomination that is WinBatch, and some obscure language-du-jour that one particular developer has been playing with.

Enter Perl3. Perl meets all of the requirements for enterprise languages. It's a little harder to find quality Perl developers than for Java or C#.NET, but still relatively easy. And, Perl fills the hole left by the giant .NET/Java machines that are most corporations' development groups. It works in all the necessary environments, and it really shines in the script environment. Its ability to cross platform boundaries with ease, its huge library of existing solutions to common problems4, and the ease with which it can be tasked to handle a range of problems make Perl an ideal addition to the common .NET/Java platforms.

Conclusion: My Point At Last

The desire to standardize development platforms in the enterprise is an understandable one. And, choosing the Java and .NET platforms -- as so many organizations do -- is a wise first step. However, it's insufficient to solve the full range of business problems across the majority of enterprise platforms.

To truly have a complete standard framework, an enterprise would do well to adopt Perl in addition to Java and .NET.

A Note on Advocacy, or Why I Wrote This Meditation

I consider myself a Perl advocate. However, advocacy in general tends to turn into zealotry, which in turn ignites a sort of techno-jihad, which ultimately results in harming the reputation of that which one set out to advocate. I think this often stems from a personal ego-attachment.

However, I think an important piece of this Perl-advocacy-cum-zealotry phenomenon is the desire to see Perl replace such popular langauges as Java and VisualBasic. The problem is, managment has seen a business benefit from using these, and are unlikely to switch away from something even on the merit of technical superiority -- much less so on philosophical superiority, which is where the bulk of Perl zealotry lies.

This meditation developed as a sort of expression of how I see Perl from a management point of view. That is, I see Perl as a way to augment the gains management sees from their established platforms. If organizations can be convinced of the value Perl has as part of the Enterprise Language Trilogy, then the Perl community has an opportunity to demonstrate how often Perl is a good choice. This, I hope, would help to undo the years of "bad blood" Perl has somehow accumulated through zealotry and very bad, very public Perl scripts.

Footnotes

  1. Coding style is part of change control because it's largely, to my mind, enforced for the benefit of future maintainers.
  2. CVS happens to be my source-control of choice, but I'm not particularly tied to it: I strongly believe in using whatever the dev team is comfortable with, so long as the important features (multiple checkouts, merge process, etc.) are there.
  3. By "script environment", I mean non-interactive applications and minimally-interactive administration tools.
  4. I know, I know -- finally. ;-)
  5. CPAN, of course.
<–radiant.matrix–>
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

Replies are listed 'Best First'.
Re: The Enterprise Language Trinity
by xdg (Monsignor) on Jul 24, 2006 at 21:00 UTC

    ++. Nice piece. I like the attempt to frame the problem and break it down. I particularly like the initial cut at a definition. However, in addition to your definition, I'd like to see how you would include the concepts of architecture and scalability.

    I tend of think of "enterprise" activities as having to address issues of scale on multiple fronts, including organizational grouping, geographical locations, heterogeneous processes as well as the usual definitions of scalability from a technical sense. These considerations inevitably lead to questions of architecture to integrate disparate parts of the whole.

    Perl meets all of the requirements for enterprise languages

    You lay out a broad framework for enterprise software, then narrow in on a very specific set of standards for language and conclude that Perl is fitting for enterprise use. What about the rest of your framework? How is Perl fitting for software that is developed by one team and maintained by other teams? What characteristics make it suited for long-term maintainability?

    I consider myself a Perl advocate.

    If you want to improve as an advocate and ensure you avoid zealotry, write a convicing essay that makes the opposite points.

    I think this is a great start, but it's still a little too one-sided to be convincing to those not already convinced. I'd love to see a revision based on feedback received here and after you've written the opposite piece. Then it might well be the kind of stuff TPF can use for advocacy more broadly.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]

      How is Perl fitting for software that is developed by one team and maintained by other teams? What characteristics make it suited for long-term maintainability?

      The requirements-for-the-language section is meant to make that tie. It seems I need to be a little less obscure. Also, see below for why some of that was left out.

      I think this is a great start, but it's still a little too one-sided to be convincing to those not already convinced.

      I agree, this piece isn't advocacy per se, it's sort of a prelude to advocacy. The intended audience was Perl Monks. It's also just a meditation, not really an essay (yet) -- it's meant to sort of foist my thought process into a place where I can get some meaningful discussion on the idea. I had to ramble on a bit about the background so that the couple of paragraphs that represent my point had some context.

      I'd love to see a revision based on feedback received here and after you've written the opposite piece. Then it might well be the kind of stuff TPF can use for advocacy more broadly.

      If I get some meaningful feedback, I will probably do a few more meditations to flesh out the remaining arguments. Based on the feedback from those, I will consider writing an actual essay, which I suppose I will post here as well.

      Thanks for the criticism and encouragement, too!

      <–radiant.matrix–>
      A collection of thoughts and links from the minds of geeks
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet
[reply]
Re: The Enterprise Language Trinity
by Aristotle (Chancellor) on Jul 24, 2006 at 21:48 UTC
[reply]

      Thanks for the link! An excellent and well-articulated statement of the problems with perception when it comes to "enterprise-ready" systems.

      <–radiant.matrix–>
      A collection of thoughts and links from the minds of geeks
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet
[reply]
Re: The Enterprise Language Trinity
by rodion (Chaplain) on Jul 26, 2006 at 04:51 UTC
    Nice piece. Well written.

    Here are a few thoughts it provoked.

    • When I think of "Enterprise Software", I think of software where the enterprise's role is to buy it, configure it, and interface to it. Your piece talks more in terms of the enterprise building software. You may want to distinguish the two up front. There are probably others in situations like mine, where I and my team mostly "build" software, but the enterprise mostly "buys" software.

    • You identify Java as a language that can
      provide some measure of protection against mediocre developers.
       This naturally provokes the thought that that seems a valuable thing to do, and it sounds like Perl doesn't do it. "Gee," one thinks, "why would I want to bring in Perl and give free rein to mediocre programming." I think what you are talking about here is aspects of a language which constrain innovation more, or constrain it less.

      I find it implicit in where you go with the piece after that that in some places it's important to constrain the damaging side of innovation, and in others it's important to encourage the positive things innovation has to offer. To give examples outside of software, no one wants a thoroughly innovative surgeon, or an unimaginative sales force.

      I think it's worth thinking about whether or how to make this dilemma more explicit in the piece.

    • You might make the case for one-off pieces of code with an argument along the lines of the following:

      • Any command line with one or more pipes is a program.
      • It's usually so brief or reproducible that it's not worth retaining a copy, let alone documenting.
      • There is a place for a pipe on the command line. We would be mightily constrained without it.
      • There is also a place for something a little less evanescent than a command line. But not suffering the release overhead appropriate for a complex program. A one-off is a light-weight program, but not as light as a command line.

    • While I enjoyed the piece, I enjoyed the discussions responding to it at least as much, especially some of your detailed responses to tem. They fleshed out some fairly generalized thoughts of the piece. I'm not at all convinced there is any way to bring some of that flavor back into the main piece, but I thought I'd mention it.
[reply]

      I find it implicit in where you go with the piece after that that in some places it's important to constrain the damaging side of innovation, and in others it's important to encourage the positive things innovation has to offer.

      That's an excellent way to phrase it. I've commonly said of RUP (though I think it applies -- if less so -- to Java): "the advantage of RUP is that it protects you from bad programmers; the disadvantage is that it also protects you from good programmers." The constraints inherit in "enterprise Java" may provide some level of protection from mediocre developers, but (as you said) it also somewhat hampers good creative developers.

      It's a tightrope walk to give a development team the freedom to create while protecting the customer from the wrong kinds of creative. It's much more a social problem than a language choice problem, of course: it almost merits its own meditation.

      Thanks for sharing your insights!

      <–radiant.matrix–>
      A collection of thoughts and links from the minds of geeks
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet
[reply]
Re: The Enterprise Language Trinity
by Moron (Curate) on Jul 27, 2006 at 14:10 UTC
    The term 'enterprise software' has been unscrupulously abused by marketeers to sell software and even hardware in the manner already suggested by others. A proper use of the term 'enterprise' as distinct from 'organisation' is that in this context it includes and requires interfaces with other organisations. A typical example of enterprise software would be the software driving a wholesaler's website where retailing customers can place orders, download invoices and review their account.

    The term 'enterprise software' was first coined in the 1980's before the internet as such but after a sudden increase in the occurrence of companies doing business with each other by connecting their computers together by some means or another. The first enterprise system I worked on, in 1983, used Teletex at the client end and a teletex server running on VMS at the manufacturer's end as the means by which users in a car dealership could locate and order stock from the manufacturer, distributors or even other dealers. Unlike teletext, the user filled out unprotected fields on the TV screen using a keyboard which were passed on to VAX FORTRAN programs which would convert them into database queries (including write transactions) and then reconstruct the page on the remote user's TV screen based on the results of the DBMS query.

    In that sense such a Teletex system could be called an early example of enterprise software, which is today replaced by its website-based equivalents.

    -M

    Free your mind

[reply]
Re: The Enterprise Language Trinity
by metaperl (Curate) on Jul 25, 2006 at 18:48 UTC
    C#, while somewhat unweildy,
    I am very impressed with C#. It is cleaner and more lightweight than Java (based on the Petshop comparison) and eliminates the issues with C++. Basically Microsoft watched the development of Java and C++ and waited for enough hindsight to improve on the flaws of both.

    I have been very impressed with this language through 18 chapters of a textbook I am reading on it. It is OO through and through with no un-necessary baggage and a very nice object model. Not only that, but the Visual Studio IDE has excellent help.

    while C#.NET works very well in Windows scripting environments, it doesn't do the job on other platforms.
    I used to think this, but C#/.Net are standardized ECMA languages and technologies. And MONO is a robust Linux/other OS implementation of .NET.
    Add to that, both languages are horrible for the "quick one-off" applications that solve so many business problems in the typical organization.
    Or, you might say: "it is horrible to cobble up quick one-off applications" because of the resulting issues with documentation and code quality :)

    I am the recipient of a large body of such "quick one-off" Perl scripts (I dont think "application" is ever one-off , do you?). And personally, I would rather something take longer and be well syntax-checked and modelled and documented for future developers than what I have to deal with now.

    Not only that, but I think you will find C#.NET much faster for rapid GUI development.

[reply]

      Basically Microsoft watched the development of Java and C++ and waited for enough hindsight to improve on the flaws of both.

      Actually, MS developed a Java environment, extended it, and then got sued by Sun. In response, they pulled it, made some more MS-extensions and changes and branded it C#. Not that it's automatically bad, mind you.

      C#/.Net are standardized ECMA languages and technologies. And MONO is a robust Linux/other OS implementation of .NET.

      First, just because the language is standardized doesn't mean it's particularly suitable for a particular kind of work. My experience tells me that .NET falls down for scripting environments outside of Windows. As for the Mono project, while I'm very supportive, it's not ready for prime-time -- and even when it is, it will not do a lot to enable the kind of tight OS integration on Linux that .NET is known for on Windows.

      C#.NET certainly has its place, but it's not a panacea. Which is the point of this meditation: nothing is a panacea, and any large organization needs to use several languages to fill all its needs.

      Or, you might say: "it is horrible to cobble up quick one-off applications" because of the resulting issues with documentation and code quality :)

      A quick one-off doesn't automatically mean a poorly-written one-liner. There are, and always will be, legitimate needs for single-use programs that need to be developed to fill an urgent need. They should still be properly documented and written in a maintainable style, but these apps often don't get to (and really don't need to) follow a complete lifecycle.

      You can argue until you're blue in the face about how bad of an idea that is, and I will agree with you. Unfortunately, it's a fact of doing business until all managers become more tech savvy and far-sighted. And never make mistakes.

      Not only that, but I think you will find C#.NET much faster for rapid GUI development.

      First, faster than what? Second, I specifically pointed to Java and C# as being strong in the GUI (desktop) and web development areas. They are excellent choices, depending on your needs. Where C# falls down, as I said in the original node, is in its abilities for scripting environments (other than Windows) -- that is, where GUIs don't matter.

      You seem to be missing the entire point of the meditation, which is that it's damn foolish (in any common case) to run a large organization entirely on Java, C#, or Perl. Even just two of those is difficult. Each has places where they shine, and each has places where they suck. It's the old mantra: all software sucks. The point is, if you choose Java, C#, and Perl, you get a solid system because they don't all suck in the same ways.

      <–radiant.matrix–>
      A collection of thoughts and links from the minds of geeks
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet
[reply]

      If they did not watch just C++ and Java they might have come up with something much better, much more up to date. With a type system that does not force you to spend ten percent of your typing typecasting for example. With a system of functional pointers (oh, sorry, delegates) that doesn't require a hundred characters to get anything at all done. With real closures instead of the ones restricted to a single object. With in place closures so that you do not have to name something used just once and then scroll two pages up to find that single line statement surrounded by five lines of nonsense required by the language in order for it to be a proper method. Etc. etc. etc.

      Don't talk to me 'bout C#. I've had to use it.

      Jenda
      Support Denmark!
      Defend the free world!

[reply]

Back to Meditations