With the rapid evolution that Java and open source frameworks have made since the release of J2EE, enterprise Java IT seems to be producing too many Java dinosaurs. Developers, technical managers, or architects who no longer pursue their technical skills don't understand the evolution of JEE in comparison to J2EE, persistence frameworks, IOC frameworks, Web frameworks, or Web 2.0 and its effects on enterprise Java. Yet decisions are made based on out-of-date J2EE experience.
To understand this better, we need to understand relevance. Wikipedia defines relevance (the philosophical concept of relevance) as "a term used to describe how pertinent, connected, or applicable some information is to a given matter." We need to ask ourselves the following questions:
- Are we relevant?
- Do we need to be relevant?
- What are the implications of not being relevant?
- How do we stay relevant?
Are We Relevant?
I've been working on third-party applications for my company for sometime now and have been swept into the old paradigm of pure XML-based applications that rely heavily on DOM and XSLT as an architectural solution. You don't have to ask how well it performs as it passes around XML messages that are larger than a few megabytes to multiple layers of an architecture that utilize DOM on different layers and XSLT transformation on other layers, without any XSLT caching. At one time, when XML became the industry standard for message exchange and configuration, a proliferation of misuse was produced where XML and its adjacent technologies like XSLT were abused. I have to wonder as I work on this application if I should proliferate these old architectural methodologies regarding the usage of DOM, XML, and XSLT in this application. Is it my responsibility to stay ahead of the technical curve and better understand the evolution of alternate solutions such as data binding achievements and new parser strategies, and provide a better introduction of alternate technologies?
The funny flipside of this is that by the time I pulled my eyes away from this and other J2EE applications that I was working, there was an onslaught of SOA and Web 2.0 articles. I remember reading one of the first LAMP articles and thinking that this was not something I had to be concerned with and so I lost myself back in research on persistence frameworks. Of course, the next thing I knew, about two years later there is all this talk about SOA and Web 2.0. So I searched for articles on Web 2.0 and found some of the articles were almost two-years-old and that I had fallen behind these new methodologies. I was shocked that the development paradigm had changed, shifted, or expanded in what seemed like a blink of an eye. Then I had to ask myself: Was I still relevant? Am I becoming a Java dinosaur?
I began to evaluate my skill set based on current and past applications I had built. The problem with this was trying to establish a fixed point where my knowledge was relevant to an increasing scale of innovation and creating a technology gap between then and now.
Have you had this experience with technical professionals who say something like this?: "Well I built a whole application at company X using technologies XYZ and leading X number of developers. You should have seen it, that application was beautiful and still runs X users today."
I myself have done tons of development including COBOL, ColdFusion, XML/XSLT, JSP/servlet, Struts, and J2EE. I can build an enterprise Java application from the ground up using technologies like JSP, Struts, EJBs, iBatis, and WebLogic...but is that good enough in today's market? Bringing these old skills to my current job definitely helped me be a stronger developer, but I was definitely missing something valuable. I was missing the strategies and methodologies that were revolutionizing and shaping the industry such as the emergence and success of IOC frameworks, persistence frameworks, POJO concepts, Web 2.0 impact, SOA, and scripting languages.
Not understanding these concepts and how and why the industry changed was causing me to bring my outdated methodologies to the table as a way to provide outdated solutions. According to these changes in the industry, I was not totally relevant; capable, but not relevant. But if I can develop J2EE enterprise applications, I have to ask myself, do I need to stay relevant?
Do We Need To Be Relevant?
In sports and athletics, many athletes reach a point in their careers where they can't run any faster, jump any higher, or hit any stronger, and that's when they hit their peak. Sometimes reaching that peak is voluntary and sometimes involuntary. I reached that peak in swimming before I could take that competitive sportsmanship to a higher level like college. But in the IT industry, an individual has to ensure that they never reach their peak because the evolution of technology grows and reshapes itself so rapidly that there's no time to claim that we know all there is to know. I asked myself this question and thought I should evaluate some of the trends that have occurred in the industry. Just as an example, Figure 1 is a timeline of technologies and their estimated start dates, first release dates, or estimated dates of usage.
Now I needed to take what I compiled in this timeline to try to determine if I needed to be relevant, and figure out if relevance means that I have to be current. Looking at some of the dates it seems absolutely amazing how many innovations occurred in such a short window of time, and as each year progressed, how more significant and massive changes sent bigger tidal waves through the industry. The emergence of SOA as a methodology shows this with its ripple effects of products developed and designed to support its promise for interoperability to all who use its concepts. Then the emergence of Web 2.0 blows the others away with its continual creation of buzzwords, websites, and new widget kits. These sweeping innovations bring new concepts, new methodologies, and new technologies.
Now let's add a developer's career path in IT to this timeline by assuming it might include promotions to technical lead and manager. Now this does not represent by default that the individual loses his relevance when attaining these positions, but we should be aware that the positions' new job requirements limit one's ability to stay abreast of technical trends. I have been through a few management interviews to know that even IT managers are expected to let go of the technical aspects of development and architecture and focus on developing a successful IT group as well as meeting business needs.
Taking a look at Figure 2 and comparing it to a developer's career path, we can begin to comprehend what happens when a developer (who is technically relevant) becomes a manager (let's say at the beginning of 2005). If that manager is trying to play a technical role and isn't delegating technical decisions to developers with the relevant skills, he can't be properly informed about some of the evolving technologies such as EJB 3.0, Struts 2, AXIOM, XQuery, Google Web Toolkit, Grails, XQuery, or JPA. These technologies and the concepts that drive them have transformed and redefined the way we develop enterprise applications with J2EE through new methodologies and concepts such as dependency injection, POJOs, persistence frameworks, Web frameworks, XML parsers, SOA, and Web 2.0. By understanding these technologies and their needs, we can better understand the transitions from previous technologies to the technologies that exist today.
When talking about being relevant, we need to determine if being relevant is the same as being current. I believe that being current with today's technologies absolutely drives us to be relevant. Many times, being current is discouraged because of labels like "bleeding edge." But methodologies aren't "bleeding edge"; the implementation of those methodologies can be "bleeding edge" like APIs and frameworks. The problem is that it's still important to understand the focus and purpose of these APIs and frameworks to be able to defend or question the way we do development.
For instance, when the Spring Framework came out, many of the J2EE developers and managers that I interacted with called the framework too "bleeding edge," but they were either referring to the API or the fact that they knew nothing about the Spring Framework and so it was easy to label it "bleeding edge." Many of the concepts and issues addressed in Rod Johnson's books called Expert One-on-One J2EE Development without EJB and Expert One-on-One J2EE Design and Development were not "bleeding edge." Topics discussed like object-relational impedance mismatch, container dependencies, testing complexity, object coupling, and separation of concerns weren't "bleeding edge," but very relevant to understanding what J2EE was leaking into our architecture and where it needed to go to become more successful as a specification. Both responded with the rising success of the Spring Framework and the introduction of EJB 3.0, as well as concepts such as dependency injection, AOP, and POJOs. We absolutely need to be relevant and current.
What Are the Implications of Being Irrelevant?
One of the anti-patterns most dangerous to the success of Java projects and architectures are Java dinosaurs - those who do not stay relevant. Just as dangerous as those who do not stay relevant are those who think they are relevant but are not. When we take these two types and put them in roles of leadership, they make decisions on architecture and technologies based on a non-relevant knowledgebase. The problem with technical managers or architects who don't stay relevant is the essence of an ivory tower: they become disconnected from the innovation and motivation that drive change in the IT industry. In some situations where an architectural team does not exist, technical decisions become the responsibility of the technical managers and they become ivory towers of technology, holding back the evolution and progress of their development teams.
In some of these situations, relevant and motivated engineers identify new and possibly better innovations in technology and methodologies. These are presented to the technical managers or architects, but unfortunately without being current with the changes in IT, these leaders don't have the proper information to make an informed decision. The results of these interactions often turn motivated engineers into frustrated engineers whose skills and drives are not given proper respect or the opportunity to drive innovation in their groups. The problem is, as many of us know, it doesn't take long to lose relevance.
These engineers constantly have to decide whether staying loyal to their current companies and becoming less relevant is more important than going where their relevant skill set leads them. Technologies and methodologies change so often that we quickly lose the vision of our experiences and how to best leverage innovations in the marketplace to better drive our direct IT needs. Being relevant is not always about reading up on the latest technologies, but it's very important to understand the latest and greatest to understand trends in the industry and whether or not those trends are relevant to our business.
How Do We Stay Relevant?
Java dinosaurs need to understand that it's no longer just about IT adding value to the business; it's also about the business adding value to IT. The way the industry is moving is providing a new vision of where business can be agile enough to meet immediate needs and may require from IT, capabilities that IT may not be ready for. Business and its drive to be more agile and its ability to drive down operating costs directly impact how they will use IT and therefore change the way that IT operates. It's our job to harness the technologies that help drive IT to be agile enough to react to the needs of business in the time required. We do this by working together as a team and breaking down the barriers of outdated skill sets.
Where do we go from here and how do we keep driving our skills forward? There are so many industries that require continual education from accountants, doctors, and teachers, and yet IT does not have the same requirements. The unfortunate part is how many businesses put training on the backburner of their organization, especially since many organizations have great assets internally that can be used to educate and train other individuals. We must strive to use our resources internally to create a broader and stronger technical knowledge base. Each developer or architect should always be able to "validate his worth" by assessing his skills against the current market and against the vision and direction of his current organization. This is sometimes a difficult challenge because many engineers might feel that they are underpaid for the value they provide their IT organization. Every IT person should be able to take stock of their skill set and validate that their skills match with what they are being paid to do. IT is an ever-changing and ever-evolving industry as we know and the day we feel we have reached our peak should be the day that we retire.