Forging an enterprise Flex team

Given the time and the resources, building a stellar Flex team may seem an easy-enough task. The Flash platform, however, is an unusual beast—appealing to developers of very different backgrounds, ranging from old Flash Pro whizzes to grizzled Java veterans. Finding the unifying skills to put together an efficient and well-oiled team can be a daunting task.

This article is both for managers looking to assemble a team in the enterprise space, and for developers keen to refine their skills to suit large, complex projects. I'll cover some of the common strengths within the Flex community and show how these abilities can work together to forge a solid foundation for your new project. Following that, I'll focus on some of the key decisions your team will have to make—surrounding tooling, automation and best practices—as they get up and running.

Note: Projects of this size are bound to be influenced by many external factors. These include existing infrastructure within the organization, branding/style guides, supported tools and frameworks, current processes, and upstream systems, just to name a few. While the development team assembled will recommend the best tools for the job, many of the decisions will need to be advocated by a manager with the political will to champion what the team needs to build the best product possible. Indeed, even within the team, there needs to be constant access to the product owner who can provide decisiveness from the business if and when the team find themselves locked in a stalemate. Without these processes in place, the productivity of the team, and that the project itself, will suffer.

While every potential team member has unique specialties and interests, they all have inherent knowledge gaps as well. A great team should highlight all those strengths and improve on the weaknesses. Putting together the right elements to make the most of the platform involves aligning these strengths across the team and ensuring that the atmosphere is challenging, respectful and stimulating—thereby not only creating an effective product, but also improving the team's individual and collective abilities.

Here are a few of the key skill areas to focus on when building your team:

Note: These skills are by no means mutually exclusive; in fact, it's highly likely you'll have team members who exhibit many of these characteristics.

• The Visualizer
  Any line-of-business application is going to require an unholy amount of data grids, custom itemRenderers, and charting components. While any Flex developer worth his or her salt has worked with grids and itemRenderers, having at least one specialist on your team will pay off in the long run. Your data visualization expert will be able to see beyond the normal grids and charts. When combined with a talented user experience (UX) team (which I'll cover shortly), the Visualizer creates some truly unique experiences that quickly differentiate your application from the competition. This value-add will be easy to quantify with your end-users and will pay dividends before long.
• The Controller
  The Controller specializes in the granular management of custom controls, such as data-driven containers and layouts; the component lifecycle is the Controller's bread and butter. Controllers typically know the inner workings of all the major controls—they bind data in their sleep—and they may very well moonlight as Visualizers. A component specialist—especially one with data-driven design experience—will work wonders when scoping out new functional areas.
• The Player
  The Player is your resident Flash Player guru, having worked extensively with Flash on all supported platforms. As such, your Player typically understands the idiosyncrasies within the Flash Player itself and how best to leverage that knowledge for the benefit of the team. Also falling under their purview—although often spread across the team—is application profiling and performance testing, preventing memory leaks, and improving CPU usage.
• The Scientist
  Everyone on your team should be comfortable with object-oriented programming (OOP) and understand the values of abstraction, polymorphism, and loose coupling. Design patterns, while important, aren't nearly as fundamental as a solid understanding of OOP and the ability to map out an object model from a given problem space. That said, at the very minimum, each member should have a strong understanding of the Model-View-Controller (MVC) architecture and Dependency Injection (DI). The Scientist will add value by "trimming the fat" from your application via the refactoring of inefficient code and generally finding "clean" solutions to difficult problems. Scientists are often also handy when it comes to visualizing the problem space, creating diagrams to describe complex interactivity—also useful when onboarding new members. The Scientist might not necessarily have a strong Flex background, but should be able to apply software engineering best practices to the application.
• The Negotiator
  The Negotiator is your services specialist. Negotiators focus on the communications between Flex and the service layer (the collection of consolidated services with which the client communicates and which typically abstracts downstream applications). This ranges from simple HTTP and XML requests to the more efficient binary transfer protocols such as AMF (for Flash Remoting) and RTMP (Real Time Messaging Protocol). If the application has to handle large amounts of real-time data and deal with concurrency issues due to high numbers of simultaneous users, familiarity with messaging and, optimally, Adobe LiveCycle Data Services (LCDS) will go a long way. It is helpful if the Negotiator has first-hand experience with the service layer infrastructure; he or she will also benefit from understanding the idiosyncrasies of the implementation. Indeed, the Negotiator may well come from a service-oriented background.
• The Framer
  Your Framer is the team's go-to for framework discussions and best practices. Framers are well-versed in all of the features of the chosen framework (or frameworks) and know ways to customize and extend it to suit a large modular application. By using their expertise, you'll make the most out of the micro-architecture, aiming both for clarity and consistency across the project. Good framework usage will also cut down on redundant code and improve the accessibility of the application to new developers.
• The Builder
  The Builder will manage the automated compilation of your Flex application. As your project increases in size, so too does the complexity of the build script. Dependency management, resource provisioning, code optimization, automated unit tests, and code coverage reports all fall under the Builder's purview. Some teams opt to hand over this role to the server team, as they are often more familiar with automated build management.
• The Architect
  An Architect will typically have strong skills in all areas, although framework, OOP, and service specialties will go a long way. The Architect will see across the entire team (or teams) and map the core module/package structure for the entire project. Working with framework specialists, the Architect will provide a robust and consistent method to communicate between the various modules. They will create a strong and reliable development environment where each developer can easily construct, rework, and rebuild various modules without interrupting work in other teams. They will also work closely with the services team to create a consistent and reliable API with which the application can interact.

In addition to your all-star development team will be a solid User Experience (UX) component. I won't go into the specifics of UX here, as a thorough overview warrants its own article; however, there are two main players to highlight:

• Design/UX: The Creative
  The Creative's job is to develop the detailed artwork on which the application relies. More often than not, the Creative will produce this work in Photoshop or Illustrator and pass it on to the integrator.
• Design/UX: The Integrator
  The Integrator is the bridge between the Creator and the rest of the team. In the past this was achieved via the Flash authoring tool (part of Creative Suite), visually constructing assets and skins that were then compiled and given to the team. However, with the advent of Spark and the new skinning model in Flex 4, the process now revolves around Flash Catalyst. In essence, the workflow involves importing the artwork, tweaking it, and translating it into components that are then exported into a packaged XML format that the developers can easily integrate into their environment. Incidentally, this burgeoning role is also prevalent in Silverlight via Expression Blend, and is one very big argument for both platforms over HTML5.

Note: A UX team coming from the web paradigm may not adapt directly to rich Internet applications (RIAs). Whereas a web site is typically static (with the exception of highly dynamic Ajax-enabled web-applications), Flex applications are stateful and do not require the reloading of a page to process an action. Some coaching may be required to transition an existing web team into RIA design.

Putting together your team is merely the first step. There will be many key decisions facing your newly formed team, and while everyone will have his or her own preferences and opinions, it's good to be prepared for some of the issues.

Here are some of the more significant decisions facing your team:

• Standards
  Your team will need to agree on coding standards and, as you can imagine, consistency is the key. While this is fairly straightforward when working with a new team, it is easily overlooked when adding members further down the track. These decisions are about more than just class and package naming conventions. They include standard approaches to module loading and communication strategies, framework usage, unit test coverage—even down to the choice of IDE that your team uses and wikis for documentation. There are tools you can employ to ensure new code adheres to your customized standards—Flex PMD being the most common.

  Aside from coding, standards may take the form of client/server APIs, XML schemas, build management, user experience, and documentation. These standards should be well defined and enforced across all practices and deliverables to ensure consistency across the project.

• Source Control
  Every developer has their favorite flavor of source control—from CVS right through to Git. However, you'll most likely be integrating with a server team who have their motivations—and an optimal solution may well cover both the client and server. Keep branching and merging in mind when choosing the provider: the larger the project, the more important these staples become.

  Another factor that may influence the decision is the variety of tools that integrate with source control. These include IDE integration (most major providers have Eclipse and IntelliJ plugins), code-reviewing software, and project management tools. The latter in particular are going to go a long way in placating those BAs who regularly pull hair trying to track project development.

• Automated Testing
  Comprehensive testing is imperative in modern software development. Automated testing, along with a good quality assurance (QA) team, can ensure that new changes aren't silently undermining past work. While unit tests (a must-have) are well covered by FlexUnit (now bundled with Flash Builder), automated UI testing can well turn into a point of contention. Just as the refactoring of code or the updating of an API can break unit tests, so too can an updated design destroy clearly defined click-paths and interactions. Nevertheless, you have a slew of options out there to manage UI tests—although FlexMonkey and QTP are two of the most common.

  While automated unit testing in Flex is well supported, integration testing is not. The fact remains that automated integration testing in Flex is still fairly fertile ground, and it's up to each team to determine if the benefits outweigh the costs. Often, manual integration tests—performed both by QA departments and the developers themselves—are sufficient.

  One final aspect to consider is performance and load testing—that is, gauging both the responsiveness and capacity of the application, respectively. Depending on the business needs, this could be the purview of a single developer or, better yet, the responsibility of the entire team. Popular tools include HP's LoadRunner and WebORB's CloudPuncher.

• Build Automation and Dependency Management
  Almost every project—and particularly agile ones—benefit from continuous integration. To support such an effort, build automation is essential—in other words, dedicating a server to regularly build and deploy the latest version of your application. This process is going to have to know how the project is structured and what the dependencies are in order to build from a script.

  There's bound to be some contention among your team over the system used for both build and dependency management (DM). Two of the main contenders are Ant (using Ivy for DM) and Maven (using Flexmojos, the de facto Maven plugin for building Flex and AIR applications), both of which come from the Java world, and both of which have their pros and cons. Keep in mind that the goal is to have a robust and flexible solution; whichever way you go, ensure everyone is on board and aware of the duties required.

• Frameworks
  While laborious framework debates permeate much of the Flex world, the choice of framework (or frameworks) is a significant one indeed. Apart from providing a standardized methodology of communications within the application, the choice of framework will directly affect your team's output—both in capacity and in content. A legacy provider such as Cairngorm 2 (the vanilla version at least), while well-known amongst the community, is notorious to unit test and become ever more complex to manage as your application starts to scale. PureMVC, on the other hand, while ultra-portable, may very well bog your developers down in excessive overhead in order to provide versatility that your application might never need.

  That said, the more modern frameworks that support inversion of control (IOC), such as Robotlegs and Parsley, are both mature and battle-tested providers that add a lot of value managing client-side architecture. Regardless of the decision, it behooves the team to identify, outline and adhere to a consistent methodology.

• Services
  Much of your decision around client/server communications will be based on either existing standards within the organization, findings from the architects, or both. Nonetheless, Flash Remoting (sending strongly-typed objects between the client and server via the binary AMF protocol) is more than likely to be the bare minimum you'll employ—and this can be achieved with a number of tools, most prominently either BlazeDS or WebORB. A more comprehensive and robust solution will leverage LCDS, which uses the RTMP protocol (and thus Flash messaging) and a publisher/subscriber model to push data back to connected clients.
• Integration
  Dealing with both a client team and a server team is no mean feat. Encouraging the teams to agree on an API early in the project is essential to ensure everyone is on the same page as to what exactly the service side will provide and the terms of the exchange. Once established, a thorough API ensures your client team are working to spec regardless of the status of services. A quick mock-up of the service layer in Flex will often prevent any loss of productivity while the server team work on their part concurrently.
• Choice of SDK
  If you're starting a new project, one of the only reasons you could muster to use the antiquated Flex 3 would be the lack of experience your team has with Flex 4. The productivity gains with the improved skinning and layout mechanism in the fourth iteration of Flex make the decision a simple one indeed. Unless there is a strong business case for Flex 3, your team should be working with Flex 4 and Spark. You'll also benefit from Flash Catalyst—which, while still young, is nonetheless a promising tool for the future. Flex 4.5 has recently been released and, along with improvements in RSL loading and mobile support, it also exposes skinnable DataGrids for the first time.

Flex attracts both the modern and the adventurous developer. Putting together a well-balanced team of professionals for this burgeoning platform can take some work-backgrounds and experiences differ considerably among the community. Focus on covering the key areas of the platform and you'll create a solid product leveraging the best that Flex has to offer. Be mindful of the obstacles and hurdles early in the game, and you'll be securely placed to release, support, and maintain your application well into the foreseeable future.

For more information, check out Adobe's comprehensive list on Flex-related products.