As a member of the Sencha Professional Services team, I spend most of my time directly interacting with our larger enterprise customers. Our team offers a wide variety of expert services, and in many cases, we spend weeks working side-by-side with a group of developers helping them to create, build and deploy incredible applications using Sencha products.
I recently had an opportunity to work with one of our enterprise clients, helping them define how Sencha should be used within their organization. I wanted to share some lessons and high-level concepts about enterprise architecture with the community that I think will benefit everyone.
Table of Contents
Working with the Enterprise
Working at the enterprise-level can be both very cool and very frustrating. On the one hand, I get to build really challenging apps; but on the other hand, enterprise applications often target legacy browsers and are prohibited from using cutting-edge technologies.
Having said that, I am starting to see many of our enterprise customers rethinking their development strategies and IT infrastructures: workstations are being upgraded to modern versions of Windows, and workers are being given more choices for a web browser. In some cases support for IE6 and IE7 are being dropped completely!
More importantly, I am noticing that enterprises are standardizing their development platforms to create an ecosystem of applications that can be maintained by a diverse team of developers. Because Sencha tools and frameworks are becoming the preferred development platform in this ecosystem, the Professional Services team has been helping our customers define their internal policies, training procedures and best practices in order to facilitate a transition to this new standard.
Why Development Standards Matter
As a consultant, I constantly preach the benefits of having maintainable code:
- Applications are faster to produce
- Applications are easier to debug
- New features are easier to add
- Code has fewer bugs
- New developers can be trained quickly
We all know that time equals money, so applications that take less time to create and maintain cost less money. Ultimately this makes managers, executives and shareholders happy. Because enterprise companies have many applications in production (both internal and external), it is critical that each member of the development team be able to jump onto any project in order to deliver on time and stay under budget.
Enterprise development teams often employ many developers distributed across large areas and contain a wide variety of skill sets. By standardizing the training, tools and best practices enterprises hope to decrease development time and costs while increasing the quality and lifespan of their applications.
Sencha as a Standard Platform
When enterprises decide to make Sencha tools and frameworks a standard for application development, they’re often communicating a need for consistency across their internal and external applications. This consistency usually includes both the UI (styling, widgets, functionality) and the underlying code (architecture, libraries, best practices).
Every company using Sencha tools and frameworks should consider creating a centralized repository of resources and best practices for their development teams. While the specifics of these resources might differ between companies, the following areas should be clearly documented to help developers get started and maintain consistency across projects.
Developer Onboarding and Training
In my experience working in an enterprise, it can be difficult to get the tools you need installed on your machine.
Most enterprise companies have a highly defined IT infrastructure, so new developers are forced to wait while all required hardware and software meets approval. This process can often take days to complete, and afterwards workers remain unsure how to request additional resources. In short, new developers lack access to a clear onboarding roadmap.
For Sencha customers, I recommend that a handful of onboarding procedures be clearly documented to lubricate this process:
- Required development tools
- The process for requesting network credentials
- Standard development workflows
- How to access the Sencha forums and support portal
- What Sencha training opportunities are recommended/offered
It’s important to remember that while developers don’t need this information on a frequent basis they need to know how to access it.
One benefit of working in an enterprise is that developers usually know the exact specifications of the environments they need to support, but historically these environments have been troublesome for web applications.
As enterprises move forward with hardware and software upgrades, it is important that developers deliberately document their current list of supported environments. This list might include things like:
- Browsers (e.g. IE8, Firefox)
- Operating Systems (e.g. Windows XP,7)
- Devices (e.g. Lenovo ThinkPad)
Having this knowledge clearly defined before starting new projects (and while maintaining legacy applications) helps to improve the accuracy of the delivered products. It also allows developers time to request any new hardware/software for testing.
“In some cases support for IE6 and IE7 are being dropped completely!
On the other hand, this knowledge also helps to point out potential weaknesses. For example, the latest Firefox versions will auto-update themselves and support a wide variety of modern web standards; IE8 does not. Developers who understand those implications can avoid development practices that might collide with the defined supported platforms.
It is also important to document the specific products or platforms being used in the development process. This list might include:
- Frameworks (e.g. Ext JS 4.1.x, ASP.NET MVC 4)
- 3rd party libraries or components (e.g. other charting packages)
- Supporting technologies (e.g. SASS)
- Workarounds (e.g. using JSONP)
This supplementary list is not only helpful in defining what products or platforms are required for development, but it can also define the skill sets necessary for employee acquisition and training.
Internal Best Practices
Development teams should also decide on a list of best practices, so all developers can contribute code without compromising maintainability.
The list of best practices can be short and high-level or long and detailed; the choice often depends on the size of your team and how the developer roles are organized.
For example, some high-level best practices might include:
- Overall architectural decisions (e.g. namespacing, file structure)
- Security implementations
- Error handling
- Shared libraries and custom components (UX)
- Testing, builds and deployment
…while some low-level best practices might include:
- Whitespace usage
- Commit practices
- Console usage
- Browser Strict vs quirks mode
In my experience, enforcing the low-level best practices is difficult to do without mandatory code reviews. While code reviews are a fantastic way to teach junior developers, maintain code quality and stimulate creativity, it’s not something typically done in most enterprises.
What are your thoughts?
This article highlights some ideas for implementing development standards in large organizations but is far from a comprehensive plan. The Sencha Professional Services team provides a variety of services including high-level architectural reviews, deep analysis of application performance, custom UX development and everything in-between, and we can tailor an engagement to fit each customer’s specific needs. The concepts above are a good start and should translate easily into any business.
If your company has implemented a set of development standards, please share your thoughts and experiences!