While reviewing some information on software architecture, I recently re-read “Who Needs an Architect” article by Martin Fowler. He was quoting his exchange with Ralph Johnson on architecture, and I think this piece illuminates root cause of most software design problems:
One of the differences between building architecture and software architecture is that a lot of decisions about a building are hard to change. It is hard to go back and change your basement, though it is possible. There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. That, and duplication… Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world…
Another powerful thought is that most of a system’s dysfunctionalities are driven primarily by its stakeholder’s vested interests.
And lastly, Conway’s Law :
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
So, in conclusion:
We have met the enemy, and he is us.
JavaScript has gained a sizable following and has experienced resurgence in last 6-8 years or so. Compared to a client-side JavaScript that most of the developers were primarily using 10+ years ago, its evolution (semantics, engines, browser/device support, and frameworks) has been rapid. With an advent of Google’s V8, Mozilla’s Rhino, etc. engines, there has been a staggering proliferation of client side and server side JavaScript frameworks and platforms.
There is a litany of tutorials and opinionated articles and posts on the web on this topic, so my goal is not to dive into deconstructing various frameworks, but rather present a SWOT analysis on overall JavaScript platform. In addition, I will share my thoughts on how server-side JavaScript, such as Node.js, can be fit in and integrated into established enterprise architecture.
SWOT analysis:
Front-end JavaScript is now ubiquitous across variety of web applications, be it large corporate sites or startup web apps and SPAs (single page apps). There are some well established (JQuery, Dojo or widget APIs, such as JQuery UI, etc.), as well as emerging libraries and JavaScript frameworks available, which generally present low technical risk.
On the other hand, server-side JavaScript requires careful consideration as stakes are high when it comes to large volume transaction processing, corporate data access or legacy system integration. Additionally, the problem sets we are addressing with server-side scripting are very different compared to front-end. However, there are clear benefits of adopting server-side scripting.
First, functional scripting languages significantly boost developer productivity and should be the first choice when it comes to internal utilities, devops tools, and proof of concept or prototype implementations. Server-side JavaScript fits nicely into this category. Corporate development teams sometimes tend to stagnate when it comes to choice of supported tools and languages. Using JavaScript in this context would allow development staff to get necessary exposure and provide opportunity for learning in a relevant context.
Secondly, in addition to productivity gains, Node.js platform that runs on Google’s V8 JS engine is now a de facto choice for scalable, high performance, high throughput event based server side processing among startups and select technology centric firms. It has become a proven technology to a large degree with backers such as PayPal, Netflix, and LinkedIn. Favorable performance comparisons to JVM based back-end have been published as well. Moreover, with Java 8 Nashorn arrival and upcoming C/C++ integration with Node.js, one can see the importance of the server-side JavaScript technology in an enterprise architect’s arsenal.
Node.js platform is known for providing highly performant, asynchronous, event driven request processing and is best leveraged in stateless, multi-user, high traffic web applications. Node.js could serve well as a lightweight facade to an existing enterprise system consisting of service-oriented modular components, exposed via HTTP based web-services, be it SOAP or REST or better yet, micro-services. This approach enables us to get to market fast with established business functionality. However, you might not be fully taking advantage of Node’s asynchronous processing power if these services are built on top of monolithic, synchronous components. In addition, if the application design relies on state maintenance and transactions, Node.js might not be suitable. To take Node.js to its full potential, it is ideal if an entire application stack is architected based on asynchronous, reactive principles. Hence, greenfield projects would likely be able to take better advantage of this technology.
Generally, to improve success rates of server-side JavaScript adoption and rollout, development organization needs to address following important concerns:
✓ Application design and architecture
PayPal and Netflix have published interesting technical posts about their experience with Node.js that illustrate some of the challenges and opportunities, as well as successes they encountered. There has also been an increase in number of Node centric developer events and conferences that companies can send technical staff to learn from the open source community, and other firms. Attendance of open source community meet-ups should also be encouraged.
As with any technology or platform, there are critics who are dismissive of anything trendy or originating in open source. They say Node is just another shiny alternative and there are no tangible benefits or it is too disruptive. The tooling is just too weak and debugging/refactoring can be unmanageable. Some of these concerns are certainly valid. This is called technical risk, and teams have to learn to deal with that. There are strategies to address this type of risk via sandbox/proof of concept projects, parallel development of same solution on proven and new platform, smaller scale deployments to run production parallel, etc. Yes, it involves certain cost overhead, but disruption drives innovation and innovative companies tend to build better products and services for their clients.
In conclusion, despite some of its weaknesses, JavaScript is mature enough at this point to be adopted by both front-end and back-end developers, and enterprise architects need to be more open to shift to reactive, event driven application design using open source frameworks, and functional languages. This will help to attract younger technical talent, as well as retain development staff, and enable corporate IT to modernize and become more efficient and flexible in service/product delivery to the end customer.
Additional resources:
The nascent of social media, web content proliferation, as well as resurgence in idea centric startup businesses naturally has led to a formation of a hybrid software development ecosystem that reaches across business borders, offers a sort of technological liberation to software developers, and architects.
A community of software engineers and technology incubators are continuously looking for and creating better frameworks and tools to develop that next billion-dollar app to solve utilitarian life problems. Having a private Github repository or active contributions to one of open source projects has become almost a prerequisite for developers seeking employment at startups.
Post IPO companies, such as PayPal, Facebook, Netflix, Twitter, etc. are a hot bed for technological innovation within software development arena and are heavy adopters and evangelists of open source. Another set of startups and spinoffs have formed around technology solutions integrated within a platform as a service (PAAS) offering, for example Pivotal (Spring, GemFire), Typesafe (Akka, Scala), etc.
Old guard firms using open source APIs are frequently advised to establish a community presence and a stable relationship with open source developers by attending meet-ups, sponsoring social gatherings, contributing to open source from within, etc. Moreover, even most traditional enterprises with stuffy IT departments have realized that innovation and tactical adoption of new technologies is key to their survival in today’s marketplace.
All of these forces have produced (and continues to produce) a tremendous number of new frameworks, APIs, and platforms to consider when faced with architectural decisions and choices on green or brownfield software projects. For example, just reviewing web frameworks – there are over 20 in Java, 7+ JavaScript based, 3+ in Scala, 6+ in Ruby, etc.
These shifts have also supported interest and innovation among existing and new programming languages – according to Github, besides Java, C++ and C#, JavaScript and Ruby were at the top of the repository leader board, moreover Scala, Clojure, Haskell and Lua were in the top 20!
However frustrating (buggy and impossible to learn all), abundance of languages and frameworks is ultimately a good thing. There are certainly forces of technology evolution through natural selection at play here. Better and stronger survive and thrive, weaker die off. It takes wisdom and foresight on a tech leadership’s side to make right choices when building extensible and maintainable software, be it a Single Page App or a large enterprise system.
Having worked for over 10 years with Java SE and EE, developing and designing traditional enterprise systems with a sprinkle of open source frameworks and APIs, as well as having had an opportunity to manage software development teams and vendor relationships, I would like to present a series of posts attempting to explore current trends and review some of the important technologies from architect’s and tech management’s perspective.
