Duane Nickull is Senior Technical Evangelist at Adobe and co-author of Web 2.0 Architectures which I reviewed recently. He is also Duane Chaos of grunge band 22nd Century and entertained us at the Adobe MAX party last night in Los Angeles.
It’s appropriate that he works for Adobe, whose Flash runtime has parallel chameleon characteristics. Most of the time it is delivering annoying ads, games or silly videos; but it also turns up as a flexible cross-platform client runtime for Enterprise applications.
We saw this demonstrated yesterday in an excellent session on scaling Flex for a large trading application, given by the developers of Morgan Stanley’s Matrix application about which I have written before. This session was far more informative than the earlier online briefing, and a fascinating case study in how to create Enterprise-grade software.
Matrix was built by a team of around 30 Flex developers, over a period of between 18 months and two years. It uses a REST-based service layer which talks to a variety of Java and .NET back-end servers – we didn’t hear much about these – and delivering XML to the Flex client. The team did not use the Flash-optimised AMF protocol because the app uses Lightstreamer which did not support it at the time, though we were told that AMF would be advantageous and may be used in future. LiveCycle Data Services were ruled out because of lack of support for edge server deployment; again, this has apparently been fixed in the latest LiveCycle so migrating in that direction is possible.
Matrix uses the Cairngorm 3 architecture, which specifies best-practice design patterns for Flex, implemented using the Parsley Application Framework. The application is modular, and we heard a lot about how rigorous module encapsulation makes a large application like this – 600,000 lines of Flex code – manageable, reliable, flexible and testable. One module cannot access the implementation details of another, and a message bus handles communication.
I was also impressed by the attention given to performance. Another advantage of using modules is that they are loaded on demand, reducing the load time and memory footprint. Each module is profiled separately. The team also found that a big factor in Flex performance is efficiency in managing redraw regions – apparently Flash can easily be sloppy about this and redraw regions that have not actually changed. The team patched the UIMovieClip component to overcome problems in this area.
A model-view-controller architecture is used for the user interface, and this enables better testability. The team uses continuous integration to maintain quality.
According to the session presenters, the result is an application that has the high performance required of a financial trading application, and can run for extended periods without issues.
Although I had the impression that developing Matrix has been bleeding edge at times, with the team using beta software to get access to new features, there was also evidence that Adobe was responding to issues and using this as an opportunity to improve its platform.
This makes a great case study for those sceptical about whether the Flash runtime is really capable of powering Enterprise clients, or for any Flex developer.
4 thoughts on “Adobe’s chameleon Flash shows its enterprise colours”
Hi Tim, really interesting write-up. I’m curious whether this was considered a success by the customer?
2 years, 30 developers ($10 million assuming $100/hour), 600k lines of code sounds like a huge investment not to mention the ongoing maintenance of such a large codebase.
For most customers I speak to the low ROI and risk on this level of development effort would be prohibitive. Do you think this is typical for this type of RIA project or was there a lot of back-end integration complexity?
In todays market I see a more common profile for RIA as be 2-3 devs, 1 designer and a maximum of 6 months to deliver.
Silverlight Product Manager
I’ve worked on Enterprise projects with the level of investment that you’ve estimated. I’ve never seen a project fail outright. When a large system “goes live” people tend to ask if it came in on time, on budget, performs well under peek load, and meets the initial functional requirements. However, it often takes a period of years to truly understand the value and costs of the project. Users of the system often have to re-engineer how they do their work to get the full benefit of the system and that takes time. And, the long term costs of maintaining the system may not be fully understood until much later. In hindsight a project that was seen as an early success may start to look like a failure. For example the London Stock Exchange and Microsoft announced and promoted their new .Net based £40m trading system as an example of what the .Net platform was capable of:
This year, after suffering an earlier seven hour trading outage and high year-after-year maintenance costs, the Exchange announced they are dumping their trading system to go with a Linux-based one.
Does that mean that .Net is a failure, or that it is too expensive to develop on, or that it has fundamental performance issues? Some people have suggested that for high transaction systems .Net is not a viable platform:
But who really knows? There are many reasons a system can fail over the long term. I’m certainly in no position to judge and I doubt a forensic analysis will ever be published or that Microsoft will do anything other than describe .Net as the best platform for everything.
Applications like the London Stock Exchange’s trading software or Morgan Stanley’s Matrix trading, analytics, and communications system require real-time access to a wealth of information. See the “Why Matrix” video introduction here:
Adobe already has a good story to tell on providing ways to develop and distribute visually rich applications. They must hope the Matrix application demonstrates that Flex is a good way to develop visually-rich real-time applications. They are also making strategic investments in providing higher level real-time data services via their LiveCycle enterprise suite of products. So this is a strategic direction for Adobe and you can expect to hear more from them in this area.
Will Matrix be a success? Given the publicity around it, Adobe and Morgan Stanley likely think it has passed most of the basic go live tests. But if you really want to know if it is a success you’ll have to ask the question again in a couple of years.
A common problem with ERP systems is that they have rigid and difficult to use user interfaces. From what I can see, Flex is being used more and more in the enterprise to provide more sophisticated user interfaces on top of exiting ERP systems. SAP has promoted the use of Flex and Web Services for this reason. Oracle is making use of Flex to provide sophisticated dashboards and rich user interfaces when needed in some of their products. So I think there are many profiles for RIA projects ranging from a few weeks work on a small project to years of work on very large enterprise projects.
John — so while I can’t comment on the specifics of the financials around the project, I do thank you for highlighting the viability and credibility that the Flash platform has in the enterprise.
Rich Internet Applications, to my mind, are an opportunity to deliver rich, immersive user-experiences that surface simplicity upon complexity. In the enterprise, Adobe continues to support customers for whom the increasing trend towards consumerization of experiences they deliver…RIAs are not simply the domain of low to medium complexity experiences within the capability of a 2-3 person development team over a small number of months. There are many enterprises who recognize that an RIA delivered on the Adobe platform can allow reach out to multiple platforms and devices for a similar (if not less) investment in development effort than previous technologies.
That the platform supports teams of 30 people across 2 year project cycles, as much as it can support teams of 3 people across 2 week project cycles, speaks to the breadth of the platform as much as the maturity. That organizations like Morgan Stanley can staff the delivery of such incredibly immersive and complex solutions by retooling and training partners and developers well versed in other enterprise technologies, whether they be J2EE, .NET or otherwise, speaks I feel to the maturity not only of the platform itself, but the ecosystem of best-practices and tooling that exists, from design pattern frameworks, unit-testing frameworks, continuous integration environments, style checkers, debuggers, quality assurance tooling integration, and all manner of other price-of-admission enterprise tooling capabilities.
As for low ROI; I’m not sure I follow…ROI is a function of understanding the business context and business challenges. With appropriate methodology, business challenges and opportunities become technology and design opportunities, and when you can bring innovative design-thinking alongside robust technology platform, the opportunity to unlock ROI is tremendous. ROI is a design problem, not a technology problem, and when technology enables the delivery of responsive, immersive and innovative user-experiences that are not only useful, but usable and desirable, then the ROI can be delivered upon that technology platform.
There are no shortage of examples of teams of 2-3 developers who have created innovative applications in incredibly short periods of time, and the cycle of design and delivery accelerates ever faster. That there are opportunities in the enterprise to deliver projects where organizations might choose to invest millions of dollars as you suggest, speaks only to the tipping point of a platform that is as relevant to enterprise as consumer application development – a convergence that we consider inevitable as expectations around user-experience in the enterprise match those of the consumer experience.
There are an incredible number of examples of what happens when 2-3 developers and a designer spend a few weeks or months working on the Adobe platform with Flash/Flex/AIR. Having organizations like Morgan Stanley step up and show what they have achieved with teams and projects of dramatically different scale, is an incredible articulation of the breadth, robustness and maturity of the platform, do you not think ?
Comments are closed.