How important is it to insert (that is, embed) enterprise Web applications within enterprise Web applications?
I'm not talking about special-purpose "widgets", like pop-up calendars and what not, which you embed in Web pages. And I'm not talking about enterprise back-end APIs, which have no visual aspect.
I'm talking about embedding a visual enterprise Web application inside a visual enterprise Web application.
For Flux's OEM customers, the answer to the above question is, Very important.
(An OEM is simply a software company that builds and sells their software application with Flux embedded in it.)
Many of our OEM customers are financial software companies selling their software products to their corporate customers. Other times, our OEMs are different kinds of software companies whose target market is financial institutions.
Financial companies want enterprise functionality, such as payments, accounts, and receivables management. As part of that enterprise functionality, our OEMs want to provide Web-based job, workflow, and business process editing and near-real-time monitoring capabilities. Flux 7.5 and the upcoming Flux 7.6 (available 12 Nov 2007) provide those capabilities.
Take the case of our fictitious friend, Gotham Financial.
Gotham Financial wants its enterprise Web application to be "branded" with their "look" -- their colors, their logo, their style. Hence the Gotham Financial style that you see in the image above.
Gotham Financial also wants its software vendor (a Flux OEM) to embed visual job scheduling, workflow, and business process editing and near-real-time monitoring capabilities in its enterprise Web application. Gotham Financial wants to enable its own staff to design workflows customized to their needs.
All of this is a capsule of why Web Embeddable is so important.
david @ flux : October 05, 2007
Previous NextI've blogged before about how I've found it difficult to hire Java quality assurance engineers. Because our Flux and Flux BPM software products are targeted at Java software development teams, we need Java QA engineers to do lots of programming to the Flux APIs in order to properly test them. We can't hire someone with the standard set of IT skills.
With this experience in mind, this is what I've done.
1. I've folded our existing QA team into the development team.
2. The development team will perform all QA work, from unit testing all the way through to integration testing, load testing, system testing, and so forth.
3. Performance benchmarks will be posted online with the Flux and Flux BPM technical specifications as well as in the Flux software manuals. These benchmarks will be updated with each major and minor software release. In conjunction with this
effort, Eric and the development team have been improving Flux's performance significantly in the last two weeks. Eric will blog about what the development team has done.
4. Known bugs are posted online in the Flux bug list and the Flux BPM bug list. As I write this blog entry today, there are 20 bugs on the Flux bug list and one bug on the Flux BPM list.
###
I take our customers' success very, very seriously. Their success is the only reason I have a job today. I like my job; I want to keep it.
I have never intended for our users to be our QA team. We are our own QA team. Logic bugs, performance bugs, and excessive database deadlocks are unacceptable. They lead to bad feelings all around, starting with our customers' own users. And that's very, very bad.
With these changes, we are redoubling our efforts to find and fix all of these bugs, both with the current Flux and Flux BPM releases and all future releases.
David serves as the president of Flux. He wrote the first few versions of Flux before it was selling well enough that he could hire Java developers smarter than himself.