Enterprise development is a moving target. Except for methodologies, the entire software stack turns over every few years. Trying to keep up-to-date is like chasing a train that is not only moving away but accelerating at the same time. Often, trends only appear in hindsight, like the fragility of the internet economy from the dotcom era (now known as the dotBOMB). Fortunately, some trends look like they may have long staying power; given the pace technology changes, that means a few years at most.
This article discusses several trends in enterprise development today: platform consolidation, dynamic languages, and service-oriented architectures. Each represents the mainstream thinking in today’s forward-looking companies. If your company is not at least considering these trends, you are in danger of being blind-sided by your competition.
Platform Consolidation
There are now two major platforms in enterprise computing: .NET and Java. Businesses have spoken loud and clear that they want to build around these two cores. This should come as a surprise to no one. After all, unless you sell software, your infrastructure IT is viewed largely as overhead. It does not make business sense to rewrite your business infrastructure every few years to take advantage of the latest and greatest. Some trends were worth skipping like the brief flurry of activity around building 3-tier desktop systems using COM/DCOM and CORBA before web-based applications took off. The trick, as always, is to determine which shiny new technologies provide a return on investment.
Technology continues to advance, and it makes sense to advance along with it so long as it offers clear advantages. If you look at the trends over the last 15 years or so, you can see how languages and platforms have changed. At the beginning of the 90s, PCs appeared in business, freeing employees from the tyranny of mainframe. The freedom offered by PCs spawned a great deal of productivity. It also produced a huge selection of development tools. For business applications, the early 90s was dominated by xBASE languages: dBASE, Clipper, FoxPro, and later, Access. Each allowed developers to rapidly create small, highly focused applications. So why are we not writing in those platforms? It is not the transition from DOS to Windows as many of these tools made that jump as well.
What killed xBASE were the limits of the languages. Ironically, parts of the languages that enabled rapid development of business applications ultimately contributed to their downfall. It is what I refer to as the 70-20-10 rule. Any special-purpose language based on a RAD framework makes it incredibly fast and easy to create 70 percent of the functionality you want in your application. However, to satisfy your users, you are still 30 percent shy of the ultimate goal. The next 20 percent is achievable, but with great effort, as you must dig behind and around the framework. Alas, the last 10 percent cannot be done because it is either restricted by the framework or language. Ultimately, as user’s desires became more sophisticated, the strengths of these languages became their downfall.
The limitations of special-purpose languages explain the ascent of general-purpose languages for building business applications. Of course, C and C++ co-existed with the highly focused languages, but were viewed as too complex. Sure, C++ is immensely powerful, but most power is wasted on mundane business applications. This explains why tool/language combinations like Visual Basic and Delphi became popular development tools. Both offered general-purpose languages that did not largely restrict the types of applications you can create. Both have good tool support and support Rapid Application Development (RAD). Using these tools, you can create applications that defeat the 70-20-10 rule because you can write any kind of application with the features you want.
Rise of Java and .NET
In the mid 1990s, a language gap was noticed. On one end of the spectrum, you have languages like Visual Basic and PowerBuilder, which offered lots of convenience features like memory management. At the other end, you have the fast, compiled languages like C++, which offered orders-of-magnitude better performance but saddled the developer with the responsibility of memory and resource management. None of these languages made for easy cross-platform development. It was in this environment that Java appeared. It solved many problems outlined above. As it was a platform rather than a language/tool combination, it created a healthy ecosystem of tool vendors, component writers and frameworks. Even though Java itself is not open source, it has produced numerous open source frameworks and tools.
Java’s design heavily influenced the design and emergence of .NET. From a platform standpoint, they are very similar. In fact, Java and .NET as platforms are more similar than different. This is a key distinction between everyone else and Java/.NET: Java and .NET are platforms, not language/tool combinations. This implies an ecosystem around the platform, not just a language. You see signs of healthy ecosystems around Java and .NET. While Microsoft dominates the tool space for .NET with Visual Studio, there are other alternatives. Many supporting elements that cutting-edge developers now use are open source for .NET and Java. These include unit testing frameworks, coverage tools, continuous integration, etc. A very small sampling of such tools appears in Table 1.
|
Tool Category |
Java |
.NET |
|
Unit Testing |
JUnit |
NUnit |
|
Code Coverage |
JCoverage, Cobertura |
NCover |
|
Continuous Integration |
CruiseControl |
CruiseControl.NET |
|
Object-relational Mapping |
Hibernate, JDO |
NHibernate |
Table 1: Tool ecosystem around Java and .NET platforms
Corporations have helped fuel this consolidation around platforms because it makes the decision process much easier. Instead of choosing between four or five vendors with tool and language offerings, companies can choose between two major platforms. Many times, this choice comes down to a simple determination: do you want to be tied to a single vendor? Many companies like the level of integration offered by Microsoft and .NET. If you use all Microsoft tools, the level of integration between them is synergistic. Some companies have been burned in the past when tying themselves to a single vendor and prefer the competitive environment offered in the Java world instead. For example, if you purchase an application server from one vendor and you do not like it for some reason, the J2EE specification insures that you can move to another vendor with minimal effort.
Between Java and .NET, the percentage of developers using each is about equal in the US. Various surveys report differences, but almost always now give one about 55 percent of development and the other about 45 percent. Interestingly, no one seems to agree on which is 55 percent and the other 45 percent. This is a clear indicator that both platforms are in a dead heat among developers. This is unlikely to change in the near future because each platform has compelling advantages for certain companies. In fact, most companies are now doing Java and .NET across departments and because of acquisitions.
Since neither platform has a clear advantage over the other, the important trend for developers is interoperability. It is a safe bet that developers and architects will soon encounter situations where knowledge of both platforms is required.
Decline of RAD
One interesting trend in enterprise development is the decline of RAD techniques for large, complex applications. RAD tools make it easy to create prototypes and small applications very quickly. However, fast development and maintainability rarely go together.
How long do you have to build the application? For example, you can build an application orders-of-magnitude faster with a RAD framework than using a more architecturally pure framework. However, if the application must live for a long time, you end up spending more time on patching and workarounds towards the end of the lifecycle than you saved at the beginning.
This is a sticky question and one that has haunted client/server development for years. Back in the mid-90s, everyone built applications using RAD tools and their corresponding frameworks, where more concern is placed on speed of development above anything else. However, as these applications maintenance and upgrade cycle lengthened, many started collapsing under the framework’s weight. Even in the cases where raw speed was not an issue (e.g. compiled versus interpreted languages), the design and architecture could not support changes without Herculean effort. Generally, this reveals itself as super high coupling and poor separation of responsibilities.
This is the dark side of RAD development. If you have an application that is:
• small in scope;
• you can guarantee does not need to be scalable; or
• will not have a long lifetime,
then using a RAD framework is the best choice. You can write the application very quickly, glossing over the design compromises that come up and proceed to other projects. If you do this, you need to get guarantees from the boss that those characteristics will not change. You might get an agreement indicating that when they change, you get to rewrite it in a more suitable framework.
Most tools now provide a RAD path to build applications, which mixes business logic, data access, workflow, and user interface. The classic case relies on components that you drop on a form and use properties to set the behaviour of all components. While extremely fast to build, updating any part (i.e., the user interface) means that you have to touch every part. When building complex enterprise level applications, using good design and not relying on the path of least resistance in the tool means that you spend more time upfront designing and modularising. In addition, you also reduce time spent in the maintenance phase of the application’s lifecycle. As you know, the maintenance phase for any non-trivial application is longer than the initial development.
Even with time constraint, it pays on the backend to use good design upfront. Unless the application meets all criteria above, you should do it right. Even though there is constant schedule pressure, you end up using less time for good design than you do by hurrying through a bad one.
Aspects
One of the most interesting trends in language development is the increasing use of Aspect Oriented Programming (AOP) in Java and .NET. AOP allows you to create language level “cross-cutting concerns” that have a special syntax. For example, consider logging in an application. The calls to emit logging statements appear in every method, sometimes multiple times, across the entire application. If you change logging frameworks, you face an enormous task to update the way all logging methods work.
When using aspects, you define what you want the logging code to look like once, then weave that method call into the existing code base using aspect tools (e.g. a special compiler). Determining where the code is placed depends on patterns within the target code. For example, you can easily add code that logs when you enter and exit every method. You can also create an aspect that logs whenever you make a database call, or call a security-related method. Using aspects greatly simplifies code that cuts across traditional object-oriented inheritance hierarchies, thus the term “cross-cutting concerns”.
Aspect compilers exist for Java and .NET. While not as revolutionary as object-oriented programming, it is an important language development. Using aspects makes writing some code that is traditionally very difficult to write easy. Aspects are currently heavily used for logging, security, transaction processing, and other service-level code that must cut across the inheritance hierarchy.
Dynamic Languages
Though enterprises have invested heavily in platforms, interest seems to be growing in dynamic languages. These are languages that are traditionally interpreted, loosely typed, and frequently used for scripting. Examples include LISP, SmallTalk, Python, and Ruby. These languages are all general-purpose and have very active developer communities.
Rebirth of LISP
One of the leading proponents of LISP is Paul Graham, whose influential book Hackers and Painters: Big Ideas from the Computer Age (O’Reilly, 2004) argues that LISP is still the most productive language in the hands of experts. Of course, most companies are not interested in hiring LISP experts. In particular, the typical technique in LISP of building a domain-specific language on top of the underlying language to create your own very focused framework is gaining traction in places like the Ruby community. This technique is difficult in strongly typed, more traditional languages. Regardless of how eloquently Mr. Graham argues for it, I doubt LISP will become a major language anytime soon. However, the languages being influenced by LISP might just have a chance, like Ruby.
Ruby and Ruby on Rails
Ruby is a dynamic language that has existed for about 10 years. Created by Yukihiro Matsumoto (Matz), Ruby includes many features assimilated from other dynamic languages. Ruby is an object-oriented scripting language designed to process text and other system management tasks. It is open source and cross-platform. Ruby resembles a mixture of Python, Perl, C/Java/C#, and borrows features like Closures from LISP.
As mentioned above, one of dynamic language’s strengths is the ability to build your own domain-specific language upon the core language, in essence creating a higher-level language perfectly suited to the problem you are solving. This has been done in Ruby for building enterprise web applications in a framework called Rails (frequently referred to as Ruby on Rails). Ruby on Rails is notable because it is so easy to write applications, literally with few lines of code. This is because the framework creates sensible defaults for common behaviours. You can customise Rails as much as you want, but use the defaults if you must. Rails contains all the pieces you need to write most web applications, including object-relational mappings, web frameworks, and even includes easy plug-ins for the Apache web server. You can see tutorials and other information about Rails at http://www.rubyonrails.com. Rails is still in early beta but already has a large (and growing) following.
The interesting thing about Rails is the vindication that dynamic languages can indeed make life much easier for developers of “typical” applications. A lot of influential people are looking at Rails as the next type of web framework. Furthermore, some companies are starting to support it in enterprises where it fits well.
Unit Testing
One of the traditional complaints about loosely typed, dynamic languages is that they do not scale well. While it is easy and quick to use a scripting language to create small applications, the loose typing becomes a burden as the application size grows, and you need strong typing to protect yourself as the complexity increases. This was the case until unit testing became popular.
Dynamic language offers more flexibility at run-time than statically typed languages, so the types of applications you can write are richer. To compensate for the lack of compiler support for typing errors, we have unit tests. Unit tests and Test Driven Development (TDD) are a strong and growing trend across all languages. Using unit tests for dynamic languages (like Ruby) allows you to take advantage of the dynamic nature of the language, without worrying about cascading errors throughout your large application because the unit tests catch them early.
TDD is an enabling factor for the growing trend of dynamic languages. TDD has penetrated most enterprise development now. Once developers are accustomed to a much safer form of development, it will assist the penetration of dynamic languages.
Service-oriented Architecture
In the 90s, client/server ruled the day, with component-based development environments, up until the internet boom and rise of distributed applications. Lately, the focus has been on service-oriented architectures. It is interesting to trace the path from object-oriented programming to service-based architectures.
From Objects to Components
Once object-oriented programming concepts became widely accepted, platform vendors used the low-level object concepts to build components. These components together created frameworks. Creating frameworks from components meant that you can assume certain characteristics of each component, such as how it interacts with other components. This allows you to create an application-wide bus into which you can plug components. Having a framework also means that a thriving third-party emerges, supplying components that plug into the standard bus.
From Components to Services
So why move beyond components? The problem with components is that they are designed to fit specifically into a bus. While it is possible to create cross-language components such as ActiveX controls, you are still limited by the operating system. Try as they might, no one was able to create a truly useful cross-language, cross-platform component model. Many attempts were made (COM/DCOM/COM+), CORBA, EJB, etc. but the elusive universal bus never surfaced until now.
Service Bus
Service-oriented architectures take the good ideas developed in component-based architectures and applied open standards to them. Instead of creating a proprietary bus for components, companies and individuals gathered to create standards for how components talk. Those standards make up the alphabet soup of today’s web services standards – SOAP, WSDL, UDDI, WS-Security, etc.
When the standards are ready and adhered to be everyone (this is the key requirement), enterprises can start deploying service buses, where coarse-grained business components are inserted to handle specific behaviour. This is starting to happen in large enterprises now – they are defining the information that flows from one component to another. This allows the freedom to mix-and-match services that are treated as black boxes. Information enters one side and exits the other, with key transformations that affect the business occurring in-between. The advantage of a service-oriented architecture is the freedom from platform and language details. If they all adhere to open standards, the language or platform where the service is implemented is irrelevant. This trend will continue because it decouples information flow and transformation from the details of implementation.
Predicting Trends
It is impossible to predict disruptive technology. All the trending in the world does not help.
Barring any major transformational shift in technology (like the invention of the Do-What-I-Mean-Rather-Than-What-I-Say language), it is a safe bet that we will see more platform consolidation and the move to service-oriented architectures in the near future. This is an evolutionary track. The future of dynamic languages is not as certain, but has the possibility to be more revolutionary. No one really thinks that Java or C# is the perfect language that will never be supplanted. Paul Graham has an interesting essay in Hacker and Painters about designing the language you will use in 100 years. My brilliant colleague is fond of saying “I do not know what you will call the language you will be using in 2010, but it will be SmallTalk”.
Neal Ford is an application architect at ThoughtWorks. He is also the designer and developer of applications, instructional materials, magazine articles, and video presentations. Neal is the author of the books: Developing with Delphi: Object-Oriented Techniques, JBuilder 3 Unleashed, and Art of Java Web Development. He has also spoken extensively at national and international conferences.
|
