John Reynolds's Blog

Business Archives

Getting Tasks to the Right Users in a Managed Business Process

Perhaps this blog on Task Routing in a Managed Process will help you to understand the issues that Business Process Developers have to deal with.

Drive the Path (process and data flow)

1. What are the steps?
2. What are the possible paths through the the steps?
3. What data controls the path through the process?
4. What data flows through the process.

When you know these answers, then start your development efforts with the process diagram and use that to drive your development path in this order:

1. Model the process flow.
2. Define the data that controls the process flow.
3. Build "just enough" user interface to allow you manipulate the data necessary to step through all the process paths.

It's absolutely critical that you do these steps in this order at the outset of your project... and once you are done you've got to do the following:

Drive through ALL of the process paths with your Business Sponsors.

If you follow these steps, then you will expose the flaws in the process flow long before you've wasted any time coding up a fancy UI that is WRONG.

The process should drive the UI, but often our haste to show a sexy screen to our Business Sponsors the UI ends up locking us into a bad process model. We've all made this mistake, and we know from experience that it screws things up for the rest of the project's life.

Everyone focuses on UI. It's the most visible aspect of a project and the easiest to have an opionion about... But in truth the best UI in the world won't make the wrong process right.

Yes indeed... the UI development tools in some BPM suites often require super-human efforts to build the sexy AJAX powered screens that are all the rage, and often you'll end up developing your fanciest UIs with supplemental tools. But that's not why some BPM projects fail...

BPM project's fail when the project team doesn't follow the steps of Process Driven Design that I've laid out in this blog entry. If you've had problems with BPM... try it my way next time. I think you'll be pleasantly surprised if you do.

Why do Java developers hate BPM?

Java developers hate BPM.

The preceding sentence is (of course) intentionally tailored to be controversial. People tend to read controversial blogs, and I'd like you to read this one. Now that I have hopefully grabbed your attention I'll tone it down a bit...

A lot of Java developers hate having to use BPM tools instead of the object oriented tools that they are comfortable with.
I work on a lot of BPM projects, and I work with a lot of other folks who work on a lot of BPM projects, and we have all encountered resistance from traditional Java developers. Java developers (in general) would rather use frameworks like Struts and Spring than be saddled with the constraints of a BPM suite.

Java frameworks like Struts and Spring are in the background... they provide just enough support to "set your creativity free" so that you can be a real programmer. You can build almost anything with Spring or Struts (if you've already mastered the intricacies of Java). They are light-weight, they're agile, and they look sexy on your resume.

BPM suites are in-your-face. They rob you of your creativity. They dictate to you how you will develop your application.

BPM suites make programming boring. They force you to use point-and-click and drag-and-drop tools to design your process diagrams, data models and forms. What's worse, they actually encourage Business People to model processes and design forms on their own... Fortunately most Business People are too intimidated to use these tools, but it does open the door for them to look over our shoulders and meddle in our affairs.

That certainly doesn't sound like something that real programmers would like, does it?

I'm not being subtle, am I?

BPM suites are a threat to traditional Java programmers. These suites are far from perfect, but even in their current state we can see where things are heading. The days of the Java Guru as indispensable are fading... We've used Java to build tools that make knowing Java itself less important, and that's opened up competition for us from folks who didn't spend years learning Java.

We're victims of our own success... and that's going to cost us.

That's why Java developers hate BPM.

The Anatomy of a Human Powered (web) Service

Human Powered Services (HPS) are the piece of the puzzle that meshes BPM with SOA... With HPS in the mix choreographing Human and Autonomous services is seamless, without HPS in the mix choreographing Human and Autonomous services is a pain.

Continue reading at my other blog...

John Gage's Ad-Hoc Keynote - WCIT2006

Senator Kay Bailey Hutchinson (R. Texas) was not able to make it to Austin's WCIT2006 for her Friday Keynote Address (due to a late Senate vote), so John Gage (Chief Researcher and Vice President of the Science Office for Sun Microsystems) pitched in with a delightful Ad-Hoc presentation.

John had spoken at earlier sessions, and given that he has a lot to say he took full advantage of the opportunity to engage a larger audience (the hall was packed in anticipation of a speech by former US Secretary of State Colin Powell)... John easily filled his alloted time, and had to be gently ushered away from the microphone by WCIT2006 CEO Glyn Meek.

John took us on a journey to many of the countries represented at the convention by enlisting Google Earth. As he flew between continents, he pointed out and zoomed in on the homes of fellow presenters and on the future site of 2008's WCIT in Kuala Lampur... and then he demonstrated how the tool could be used to visualize important data... for example the locations of reported Avian Flu incidents.

If Avian Flu spreads as many fear, the first signs are going to be from the undeveloped nations, from the mostly remote rural areas where people live in closer proximity to animals... For our own sakes we need to build out the world's networking infrastructure - starting with the poorest countries first - to insure that we know what is going on in those locales... We need to hear the news of disease outbreaks as soon as possible to prevent the feared pandemic (a compelling argument).

John went on to demonstrate another wonderful tool from www.gapminder.org that can be used to visualize Human Development Trends from around the world over the last four decades. Words Cannot Begin To Describe This Tool --- VISIT THE SITE AND SPEND A FEW HOURS EXPLORING ON YOUR OWN!

Pardon the dramatic all caps of the previous sentence... but you really ought to check this tool out... By graphing Child Survival Rates and GDP per capita income for regions (and individual countries), you can visualize dramatic trends that have taken place over the last several years. You can see countries that were once poor with high child mortality rates blossom in both wealth and health... and you can also see countries where wealth has increased, but health has not.

John makes a compelling point that tools like this can be used to strip away deciet and expose the truth... it is painfully clear which countries have successful health/wealth policies, and which do not. Knowledge (not raw information) is power, and gapminder's tools help transform raw information into knowledge that people and governments can use to the benefit of all...

John's passion for ICT (Information and Communication Technology) as a tool for a better world is contagious, and nobody seemed to mind that he over-ran his allotted time slot... We all wish he could have spoken longer, and with respect to Senator Hutchinson... I was kind of glad that she missed her plane.

Thanks John... You've helped rekindle hope that ICT really can make a difference.

Continue Reading...

Exchanging Innovative Ideas - WCIT2006

My memories of Tuesday's WCIT2006 Innovation Exchange are a bit of a blur, but it sure was fun. I volunteered to help out, and was assigned to help usher speakers to and from the podium... We started at 8:00 am, and ran non-stop until 6:00 pm... 17 speakers from Texas, Malaysia, Australia, Korea, Taiwan, Cambodia, Australia, Canada, and Mexico... and that was in only one of three meeting halls.

The Innovation Exchange was coordinated by Rebecca Judis... who volunteered for WCIT2006 last year but ended up as a Vice President for the convention ( you should always be careful what you volunteer for... it can end up taking over your life).

The pattern for the Innovation Exchange was the "Venture Capital Pitch"... 25 minutes to sell yourself and your idea to potential investors or partners. My meeting hall was filled with a mix of governments and companies... come and do business in our country, and come do business with my company.

I learned a great deal... Malaysia is like Silicon Valley but with Hawaii's climate; Koreans work too many hours a week, but that's changing; Cambodia is slowly but surely recovering from the Khmer Rouge; Mexico graduates 34,000 programmers a year. I took notes, but the sessions have still blended in my little gray cells, so I appologize in advance for any mistakes.

Some of the business pitches really roped me in... these were marketing pitches, not technical pitches... so they really focused in on relevence: Why is this technology useful? What problem will this software/hardware solve?

Joel Trammell did a great job of explaining NetQOS by using an analogy of "The mayor and city traffic": When a reporter asks the mayor "How's traffic today?" the mayor needs to be able to say "Pretty good" or "Really awful", and have a short justification... Outlining all the road closures and construction delays is overkill... the mayor needs something simple like transit time: "Traffic is pretty good, the average commute today is only 20 minutes".
NetQOS does something like this for networks... it can tell you the average transit times for messages in the network, and it can tell you where the time is being spent in your infrastructure.

Mark Spiloto pitched his company iKnowWare (pronounced "I know where")... a device agnostic view of what you need to know based on business rules, privledges and personalized views. Mark had a side-splitting video for their product... hopefully he will post it on iKnowWare's web site.

José Luque of Merkatum blew me away with their facial recognition system. His small startup created a database for the state of Florida that contains all driver license photos (and other biometric information)... it is currently the largest facial recognition database in the world, and they can match faces to photos in 4 seconds. What intrigued me by the pitch was Merkatum's intent to offer biometric recognition as a web service. If they get the funding to pull this off, they will be able to offer a very low cost solution to any company or agency that has been mandated to provide biometric verification of identity.

I had helped José get his laptop ready for the presentation the day before. He is a very charming person, and we chatted a bit about identify theft... we have both been victims. Although there are privacy concerns, the ability to more reliably prove that "I am me" before executing a transaction is very appealing (I hope these guys get rich).

Wayne Karpov of YottaYotta tailored his pitch to the convention's topic of IT and Health Care. Wayne made a very compelling argument that Health Care costs can be reduced by managing many hospitals as one... and that is an IT problem. If the databases of many hospitals could appear to be one giant database, then it would be fairly easy to write applications to manage across the multiple entities. That is essentially what YottaYotta's product does: High Performance, Resilient Global Data Sharing.

Wayne also clued us in on what a Yotta is... it doesn't have anything to do with Jerry Sienfeld. A Yotta (10²⁴) is approximately the number of snowflakes that fall on Canada in a calendar year (That's a yotta snowflakes!).

James Balestra of Safefreight showed off a nify "brick" that contains a GPS receiver and a tracking transmitter that is smart enough to switch between cell and satellite signals (satellite is way more expensive to use than cell). The brick can be attached to a truck, trailer, shipping container (you name it) and transmits information back to the company's home base. Various sensors are available (temperature, motion, etc.) and Safefreight supplies easy to use software that makes it very easy to generate views, reports, and exceptions. For example, the brick can generate an alert if its temperature exceeds a range, or if the trailer goes outside a pre-determined area.

Peter Neve of Fieldworker pitched his company's device agnostic software development platform for mobile workers... He told us that Fieldworker had originally shipped software for the Apple Newton... and I am impressed with any company with that sort of longevity in the hand-held market.

Marshall Vanderburg's Municipal Software Corporation has a sweet set of packaged applications for local governments that can be easily tailored to meet custom needs. Who knew that automating beaurocracy could be so pleasent?

Paul Hanson's Anyware Group has a great solution called ROAM (Role Oriented Access Management) that securly exposes legacy applications via any Web Browser. Paul is a hoot to listen to... he told us that a Forrester analyst compared him to a Ginsu Knife salesman... and I could see the resemblance ;-)

Daniel Gonzales of Sinapsis specializes in building "captive" off-site development teams in Mexico. Mexico has some very good programming talent, and it is in the same time zone as much of the USA. With a bi-lingual project manager, Mexico is in many ways more attractive than off-shoring development to India (for example).

As a US programmer, I am (of course) negative about off-shoring any programming jobs... but I do have to admit that there are many great programmers all over the world. Daniel's company has done a good job of enabling Mexican programmers to get work from the US by lessening the risk to US companies. The efforts of Sinapsis should help improve the economy of Mexico, and the standard of living of Mexicans... That's a good thing. The bad thing is that US programmers lose jobs...

Malaysia has great programmers, Korea has great programmers, Australia has great programmers, Taiwan has great programmers, Mexico and Canada have great programmers. There is talent out there, and they want work from the US. If we in the US want to continue to be programmers, we are going to have to figure out how to stay competitive... we have to provide more value than our colleagues in other countries, or they'll get the work.

On a more positive note, there really are a lot of clever and gifted people out there in the world, and we can benefit from their efforts (as they have benefitted from our efforts). Many of the speakers fondly referred to Thomas Friedman's The World Is Flat.

From what I saw at WCIT2006 on Tuesday, the world is also exciting... truly a worthwhile way to spend a day.

Continue Reading...

Internet-Access For All - WCIT2006 in Austin

One big focus of Austin's WCIT2006 is to develop strategies to bridge the digital divide between "Us" (people who are able to read this blog) and "Them" (people who can't access the Internet).

I am an affluent middle-class, well-educated white-guy who lives in a big city in the USA... In a world of "haves" and "have-nots" I am definitely one of the "haves". I don't just surf the Internet's ocean; I swim in it, dive beneath the waves and explore the depths. Internet connectivity is pervasive in my world (desktop, laptop, PDA, mobile phone, public kiosks, etc.) and I feel lost without a good Wi-Fi signal.

Contrast my world with that of the large percentage of the worlds population who have yet to make a phone call. We really do live on different planets... and it's very hard for us to communicate.

Communication is the point. A low cost device that is within the reach of most people is important, but the communication infrastructure is the real problem. A computer by itself is not relevant to most people. A computer (communication device) connected to the Internet is relevant to almost everyone... AMD's Personal Internet Communicator (PIC) acknowledges this fact in its very name (without an Internet connection, it's just a nice looking brick).

The technical aspects of a bridge across the digital divide are challenging, but we're really good at solving technical problems. Given the dropping costs of hardware and the expanding presence of wireless networks, the goal of AMD's Hector Ruiz to provide Internet access to half the world by 2015 seems technically doable.

The cultural aspects of a bridge across the digital divide may prove to be the bigger challenge... bridges between cultures can be disruptive and even destructive.

Internet access has a profound impact on sheltered societies: Everyone can talk to everyone and nothing stays secret for long. This blurring of borders leads us to a whole new set of tricky cultural issues to contend with... Governments and businesses need to craft policies to prepare their citizens to become active players in the new digital economy (or they are likely to become victims of it).

WCIT2006 has assembled an impressive list of speakers to debate and discuss both the technical and cultural issues posed by the digital divide.

On Wednesday morning a panel will tackle questions related to the "global impact of digital access". The panel includes Steve Rohler (Accenture), John Gage (Sun Microsystems), James Goodnight (SAS), Teresa Peters (Bill & Melinda Gates Foundation), and Yeongi Son (Korean Agency for Digital Opportunity).

On Wednesday afternoon another panel will tackle the "impact of digital access on education throughout the world". This panel includes David S. Byer (National Coalition for Technology), Veronica Kgabo (Diepsloot School, South Africa), Guillermo H. Le Fosse (Competir, Mexico), Lorie Roth (California State University), and Dan Updegrove (University of Texas).

WCIT2006 is just a four day convention, so don't expect miraculous pronouncements that transform the world... But it should be very interesting to hear what everyone has to say.

Continue Reading...

What kind of CTO do you want to be?

Recently I participated in some discussions on how to grow a management team, and I was pointed to an article by Roger Smith: "Maximizing the CTO's Contribution to Innovation and Growth",

This article is great food for thought, because it discusses what a CTO is, and it points out that there are at least five distinctly different types of CTO. The article is specifically about CTOs, but you can easily see similar characteristics in your managers, team leads and project leads.

As I read through the article, I found myself wondering which type of CTO I would be...

The first category is Genius:

“The Genius CTO is usually skilled at creating something new, possessing vision and confidence, and exploiting a unique opportunity”.

The second category is Administrator:

The Administrator CTO “must defend the organization’s budgets from overspending on technology products, services, and project labor.”

The third category is Director:

The Director CTO “is willing to give up direct hands-on research in order to create an environment in which others are enabled to do outstanding and valuable work.”

The fourth category is Executive:

The Executive CTO is used “to assist in guiding strategic decisions and managing the innovation process. The Executive CTO is a businessperson who measures innovation, research, and experimentation by the contribution it makes the company’s revenues and future competitive advantage.”

The fifth category is Advocate:

The Advocate CTO “is generally focused on the customer’s experience of and interfaces with the company…. These CTOs do not usually direct the creation of technology, but rather select and combine the best products for their specific business capabilities.”

For a moment, aspire to be a CTO. Which type of CTO do you think you’d be?

Are you doing the right things in your career to prepare you for the role? Even if you are sure that you will always want to be a programmer (and you are never too old to be a programmer), it is always a good idea to have options.

Returning to your current role; which type of CTO would you rather work for? Which of these guys (or gals) is going to make your job more fulfilling? We can’t always pick our boss, but understanding the role your boss really plays can be a big help in dealing with them.

Continue Reading...

Service Oriented Architects

In his XML Annoynaces blog, Micah Dubinko offers his perspective on software architecture and architects:

"It goes without saying that a major development project should have a solid architect at the core. A good architect needs to be able to separate personal preferences and prejudices from legitimate good design points--in other words, get the focus right. A concrete measure of an architect is whether outside groups--even ones that wouldn't normally be directly involved--are able to understand and accept the architecture. There will be times where it's just not possible to please everyone to the level of consensus, but still it provides a measuring rod against which to evaluate a design (or a designer)."

If you work with an IT group, you (like me) are probably involved in some sort of Service Oriented Architecture discovery or implementation project; Gartner predicts that SOA will provide the basis for 80 percent of development projects by 2008.

Given this huge trend towards SOA, we really need Service Oriented Architects who can "get the focus right".

Reuse is an often mentioned benefit of SOA, but I believe that SOA's key benefit is the closer mapping between business processes and the implementation. SOA meshes perfectly with Process Driven Design.

Many Object Oriented (Jave and C++) projects have great technical architectures, but the business process implementation ends up scattered across many modules and hidden in the code. When a business process changes (and they often do) it is quite often difficult (or at least tedious) to implement and deploy the process oriented changes: Not exactly what business wants.

I don't know why this happens, but I suspect a subtle impedance mis-match between form (architectural style) and function (what the program is meant to do). Perhaps Object Oriented architects tend to focus on UML Class Diagrams more than on UML Activity Diagrams?

Unlike Object-Oriented design, SOA is tailored to solve problems in a specific domain. As Miko Matsumura puts it:

"there are nearly an infinite number of software programming problems—game programming, graphics, engineering, mathematics, statistical modeling, you name it. The SOA that is getting people all hot and bothered isn't particularly interesting as a solution for all of these other problems. SOA is for business."

If this begins to sound a lot more like a Business Architect than a Technical Architect... I've made my point.

Continue Reading...

Is Java the wrong language for business programming?

Business needs applications that can be maintained long after the original coder is gone. Java is a great language, but does Java's richness lead to unmaintainable code?

This thought was prompted by a discussion with my colleague, Jim, who has managed large projects for many state agencies over many years. To paraphrase his statement a bit:

"COBOL programmers are interchangeable, Java programmers aren't"

This comment was made in the context of an effort to migrate legacy COBOL and Java applications to an enterprise-wide Service Oriented Architecture. Should we implement all future services in Java, or is COBOL still a viable option?

Jim is not a luddite, but he is tenaciously pragmatic. In his experience in managing large projects, he has found that any competent COBOL developer can maintain another programmer's code, but Java modules are often inextricably tied to their authors. Despite coding practices and design reviews, the Java modules take on the personalities of their owners. The nuance of each Java programmer seeps into the code that they produce.

You can write bad code in any language. You can write good code in any language. Is Jim's observation about Java and COBOL valid beyond his own personal experience?

I can't confirm that COBOL code is easy to inherit, but I can confirm that Java and C++ code is more difficult to inherit than assembly language**. When a language is tightly constrained, you tend to write code like everybody else. Is increased freedom leading to unmaintainable code?

Clarification: My comment about assembly language has caused a lot of confusion among some readers... I'm not suggesting that assembly language is appropriate for business programs, or that it's easier to write or maintain assembler than Java. I've just witnessed more variation in the programming styles of Java developers than in that of assembly language programmers.

Phil Murphy of Forrester Research recently dove into the issue of maintaining applications in his report:Java, COBOL, And Perl Share A Common Problem.

The report is not free to share, but the abstract sums it up:

"The wholesale loss of application knowledge creates most of the maintenance issues, whether the applications are written in Java, Perl, or COBOL."

Phil's telling us that the primary culprit of unmaintainable applications is the loss of knowledge about how those applications do what they are supposed to do, not the language that they are written in.

Let's try to rationalize Phil's findings with Jim's observation and see what we can come up with: COBOL is not a language that encourages abstraction. Java relishes abstraction.

It is relatively easy to inherit COBOL because what you see is what you get. Perhaps a boring narrative, but it has the advantage of leaving nothing to the imagination.

It is relatively hard to inherit Java because you have to comprehend the abstraction. It is like trying to explain a concept by using an analogy. If your listener shares your cultural background, an analogy can open the doors to greater insight. If your listener doesn't get the analogy, you may have slammed the doors to understanding shut. The wrong abstraction choices can destroy code maintainability.

"The problem" with maintaining Java code sometimes comes from "abstracting away" the business process and the business logic. We often use Java to write engines that execute business logic, not to write the business logic itself. In this model, the business logic itself is scattered across numerous configuration files (often written in some custom XML-ish dialects of our own design). Although in some ways an elegant approach, this coding style can be a real maintenance nightmare if executed poorly. If you can't step through the business logic in a debugger, then you probably haven't written a maintainable business application.

Back to my original question: "Is Java the wrong language for business programming?"

The answer is in how you use the language, not in the language itself.

Who will pay for innovation?

"Who can afford to do professional work for nothing? What hobbyist can put 3-man years into programming, finding all bugs, documenting his product and distribute for free?"

In 2005, Marc Fleury voiced a similar thought in a BusinessWeek interview:

"No one is going to work for free."

Marc elaborated on this in a later blog:

"Without financial compensation comparable, if not superior to, what they could earn in the proprietary software world, most of the top FOSS developers move on or simply cannot sustain the time commitment to FOSS projects demanded by the Enterprise IT consumer. "

When you think of an Open Source project in terms of the people who actually write it; what comes to mind?

Do you envision a passionate group of developers who are working on a project because they love it, or do you picture a competent group of developers who are working on a project because they are paid to?

My first direct use of Open Source was in 1990 with Michael Tiemann’s GNU C++ compiler and with Emacs. I may have been naïve, but my perception was that the folks who committed to these projects were motivated by a passion to create rather then by dreams of profit. Browsing through Linus Torvald’s recollections of the early days of Linux seems to confirm my impression; there’s no evidence that money played a motivational role in the creation of Linux.

Money wasn’t much of a open source motivation in the 80s and early 90s, but it was always a big factor. Much of the "free" software that was created during that period was funded either by DARPA or by silicon vendors like Intel and Motorola (to help sell their products). Many of these projects were carried out by consortia such as Austin’s now defunct MCC.

A lot has changed in the business of Open Source since 1990, and it reminds me a lot of what happened in Personal Computers between 1973 and today. What was started by enthusiasts and hobbyists morphed into an industry dominated by giant corporations (and low profit margins).

Since 1973 a lot of PC companies have come and go. In the early days there was real diversity: Atari, Osbourne, Apple, Commodore, Amiga, Sinclair, etc. IBM’s entry into the market, and the standardization on Intel and MS-DOS (and later Windows), removed almost all distinctions between the PC manufacturers. The only companies that were able to survive were those with the most efficient manufacturing and marketing operations. Profit marging for PCs were driven incredibly low.

When profit margins get low only companies with low overheads survive.

With FOSS cutting profit margins, what is going to keep driving innovation? My bet is that it's going to be the enthusiasts and hobbyists, not the entrepreneurs and captains of industry.

Who will pay for innovation?

"Who can afford to do professional work for nothing? What hobbyist can put 3-man years into programming, finding all bugs, documenting his product and distribute for free?"

In 2005, Marc Fleury voiced a similar thought in a BusinessWeek interview:

"No one is going to work for free."

Marc elaborated on this in a later blog:

"Without financial compensation comparable, if not superior to, what they could earn in the proprietary software world, most of the top FOSS developers move on or simply cannot sustain the time commitment to FOSS projects demanded by the Enterprise IT consumer. "

When you think of an Open Source project in terms of the people who actually write it; what comes to mind?

Do you envision a passionate group of developers who are working on a project because they love it, or do you picture a competent group of developers who are working on a project because they are paid to?

My first direct use of Open Source was in 1990 with Michael Tiemann’s GNU C++ compiler and with Emacs. I may have been naïve, but my perception was that the folks who committed to these projects were motivated by a passion to create rather then by dreams of profit. Browsing through Linus Torvald’s recollections of the early days of Linux seems to confirm my impression; there’s no evidence that money played a motivational role in the creation of Linux.

Money wasn’t much of a open source motivation in the 80s and early 90s, but it was always a big factor. Much of the "free" software that was created during that period was funded either by DARPA or by silicon vendors like Intel and Motorola (to help sell their products). Many of these projects were carried out by consortia such as Austin’s now defunct MCC.

A lot has changed in the business of Open Source since 1990, and it reminds me a lot of what happened in Personal Computers between 1973 and today. What was started by enthusiasts and hobbyists morphed into an industry dominated by giant corporations (and low profit margins).

Since 1973 a lot of PC companies have come and go. In the early days there was real diversity: Atari, Osbourne, Apple, Commodore, Amiga, Sinclair, etc. IBM’s entry into the market, and the standardization on Intel and MS-DOS (and later Windows), removed almost all distinctions between the PC manufacturers. The only companies that were able to survive were those with the most efficient manufacturing and marketing operations. Profit marging for PCs were driven incredibly low.

When profit margins get low only companies with low overheads survive.

With FOSS cutting profit margins, what is going to keep driving innovation? My bet is that it's going to be the enthusiasts and hobbyists, not the entrepreneurs and captains of industry.

Process Driven Design and JBI (Java Business Integration)

I am a big advocate for Process Driven Design. I was disappointed that PD4J didn’t turn out to be all that I had hoped for, but I still believe in (Business) Process Driven Design as the key for delivering solutions that are good for both business users and IT departments.

People tend to focus on details. If you approach someone and ask them how to improve an application, they will most likely point out some detail of the application that bugs them. Maybe they have to look at two screens to get all the data that they need:

“Could you combine those fields on a single screen?”

There is nothing wrong with requests like this, but I think the way we deal with these requests is at the heart of software’s complexity spiral.

We have to keep in mind the Big Picture… or more precisely the Big Process. The request: “Could you combine those fields on a single screen?” needs interpretation:

The design of the current screens does not match the Process that the user is engaged in.

When we are asked to make a change to an application, no matter how seemingly trivial, we should evaluate that change in terms of how it will impact the processes that are being aided by the application. Some applications, like wizards, are clearly the embodiment of processes, but others, like your email application, aren’t so clear (especially when email is an integral part of many of your business processes).

Process Driven Design begins and ends with the process the business wants to accomplish. At each step of design and implementation there is a conscious link between the details and “why”. The answer to: “Why are the fields on two screens instead of one” should be traceable from the code that implements the screens to the process(es) for which the screens were created.

One of the great things about Process Driven Design is that the requirements phase transitions smoothly into the implementation phase and visa-versa. The business process diagrams, whether UML activity diagrams or process flow diagram, insure that both the users and the developers agree on the big picture. The relationship between implementation details and the big picture requirements are more apparent, making it easier to answer implementation questions. As a bonus, it’s also easier to see the ramifications of changing requirements.

Process Driven Design can’t really succeed without a tailored infrastructure to support it. We need an “operating system” that portrays the underlying environment as “process friendly”.

Providing a “process friendly” environment is where Service Oriented Architectures come in. Services perform the individual tasks that make up each process. The middleware that routes messages to services, and which enforces loose coupling between those services functions as the “operating system”. One term that is gaining acceptance for these “process friendly operating systems” is Enterprise Service Bus (ESB).

So now we have Services and an ESB to expose them for use. The next piece we need is a Process Engine.

Java is a general purpose language suited to a wide variety of tasks. Normally that’s a good thing, but to keep things clear we need languages tailored for the task. That’s where BPEL and UML Activity diagrams come in. Pictures and words together can more effectively define a process then words alone. A Process Engine executes process definitions.

Due to events in the industry beyond the JCP, PD4J morphed into BPELJ. BPELJ provides the specification for implementing a process engine. The “nice thing” about BPELJ is that is allows you to combine “Web Services” and Java based services in the same process. I don’t like BPELJ because I consider it to be messy to mix BPEL and Java, and the approach is a half-measure (What about C# or COBOL services?).

ESB (Enterprise Service Bus) proponents take a different approach. Instead of modifying the process language to accommodate specific languages, adapters are created to connect between services and the middleware infrastructure. In Java-based ESBs, these connectors are usually implemented using JCA (the J2EE Connector Architecture) and messaging within the ESB is handled via JMS (Java Messaging Service).

The JBI (Java Business Integration) specification is the closest thing we have to a "standard Java ESB".

JBI combines "pluggable SOA Integration components with a SOA infrastructure layer, JSR 208 provides the essential building block for implementing a standards-based ESB. It also paves the path for Java middleware vendors to leverage emerging technologies such as BPEL in their ESB offerings using consistent, standard interfaces."

Continue Reading...

Pragmatic Web Forms: WebForms2

The WebForms2 proposal is a product of WhatWG (the Web Hypertext Application Technology Working Group). WhatWG is a loose consortium of browser manufacturers who have banded together to make the development of web applications easier. Rather then pursuing proprietary browser-specific solutions, they are developing technologies that can either be used by existing browsers, or can be implemented by all future browsers. Proprietary is a dirty word with this group.

The WebForms2 proposal specifically targets the question:

"How can we make it easier for developers to create sophisticated web forms?"

For example, how can we make it easier for an HTML author to add an input field to a form which will only accept a date that falls within a specific range?

WhatWG’s answer is not new technology; their answer is to define standard labels that add type and validation information to existing HTML tags and to distribute JavaScript libraries that utilize these labels.

Here's how it works: When a form is submitted the WebForms2 JavaScript parses the DOM, looking for the standard labels. If an <input> element is encountered that contains an attribute "type=number", then the input text will be checked to verify that it is numeric. If the parser encounters additional attributes such as "min=" and "max=" then further validation will kick in. This is really a quite simple technique that has been used for years... but now it's being "standardized".

Here’s an example from the WebForms2 documentation (I have underlined some of the standard labels):

<form action="..." method="post" onsubmit="verify(event)">
 <p>
  <label>
   Quantity:
   <input name="count" type="number" min="0" max="99" value="1" />
  </label>
 </p>
 <p>
  <label for="time1"> Preferred delivery time: </label>
  <input id="time1" name="time1" type="time" min="08:00" max="17:00" value="08:00" /> —
  <input id="time2" name="time2" type="time" min="08:00" max="17:00" value="17:00" />
 </p>
 <script type="text/javascript">
  function verify(event) {
    // check that time1 is smaller than time2, otherwise, swap them
    if (event.target.time1.value >= event.target.time2.value) { 
       // ISO 8601 times are string-comparison safe.
      var time2Value = event.target.time2.value;
      event.target.time2.value = event.target.time1.value;
      event.target.time1.value = time2Value;
    }
  }
 </script>
</form>

Some XForms proponents argue that the WebForm2 approach is just a band-aid since it only handles simple forms. That's a valid concern, but sometimes a band-aid is all that you need. WebForms2’s approach is limited, but it should work on any browser that supports JavaScript DOM navigation.

Why does this matter to Java developers?

If you use any of the Java Web Component Frameworks (such as JSF, Tapestry, and Echo) then WebForms2 should be on your radar screen.

For example: What would be the result of mixing and matching Tapestry components and WebForms2 labels on the same page?

On a very basic level, there’s no relationship between Tapestry components and WebForms2 labels. WebForms2 is strictly client-side behavior, and won't have any effect on Tapestry’s server-side processing. The only possible collisions are between the text that Tapestry injects on the page and the labels recognized by WebForms2.

On a deeper level, for the Web Page and Web Component authors the implications of WebForms2 on Tapestry become apparent at design time.

Design of a Tapestry page begins with the creation of an HTML template. Labels are then added to HTML elements to “transform them” into Tapestry components (all HTML elements with the jwcid label are replaced by Tapestry generated output).

With WebForms2 on the scene, HTML Authors will be much more likely to incorporate WebForms2 labels within thier HTML tags. If Tapestry components don’t recognize the standard WebForms2 labels and map them properly, key information might be overlooked. If WebForms2 becomes prevalent takes off, it will make sense to re-work some of the Tapestry components.

I'm not familiar enough with writing JSF components to know if WebForms2 will have a similar impact. The "IDE centric" nature of JSF application development could very likely make any potential issues moot. Any decent IDE can easily "pick out" the WebForms2 labels when an HTML file is imported, and map this information for any JSF equivalent components.

In any case, I am pleased with WhatWG's WebForms2 proposal and approach. They have come up with a pragmatic solution (both technically and politically) for a well understood problem. Adoption of WebForms2 requires very little effort from Web Page Authors, doesn't require buy-in from browser vendors, and promotes simplified HTML authoring.

Simplifying things is good.

Continue Reading...

Pragmatic Web Forms: WebForms2

The WebForms2 proposal is a product of WhatWG (the Web Hypertext Application Technology Working Group). WhatWG is a loose consortium of browser manufacturers who have banded together to make the development of web applications easier. Rather then pursuing proprietary browser-specific solutions, they are developing technologies that can either be used by existing browsers, or can be implemented by all future browsers. Proprietary is a dirty word with this group.

The WebForms2 proposal specifically targets the question:

"How can we make it easier for developers to create sophisticated web forms?"

For example, how can we make it easier for an HTML author to add an input field to a form which will only accept a date that falls within a specific range?

WhatWG’s answer is not new technology; their answer is to define standard labels that add type and validation information to existing HTML tags and to distribute JavaScript libraries that utilize these labels.

Here's how it works: When a form is submitted the WebForms2 JavaScript parses the DOM, looking for the standard labels. If an <input> element is encountered that contains an attribute "type=number", then the input text will be checked to verify that it is numeric. If the parser encounters additional attributes such as "min=" and "max=" then further validation will kick in. This is really a quite simple technique that has been used for years... but now it's being "standardized".

Here’s an example from the WebForms2 documentation (I have underlined some of the standard labels):

<form action="..." method="post" onsubmit="verify(event)">
 <p>
  <label>
   Quantity:
   <input name="count" type="number" min="0" max="99" value="1" />
  </label>
 </p>
 <p>
  <label for="time1"> Preferred delivery time: </label>
  <input id="time1" name="time1" type="time" min="08:00" max="17:00" value="08:00" /> —
  <input id="time2" name="time2" type="time" min="08:00" max="17:00" value="17:00" />
 </p>
 <script type="text/javascript">
  function verify(event) {
    // check that time1 is smaller than time2, otherwise, swap them
    if (event.target.time1.value >= event.target.time2.value) { 
       // ISO 8601 times are string-comparison safe.
      var time2Value = event.target.time2.value;
      event.target.time2.value = event.target.time1.value;
      event.target.time1.value = time2Value;
    }
  }
 </script>
</form>

Some XForms proponents argue that the WebForm2 approach is just a band-aid since it only handles simple forms. That's a valid concern, but sometimes a band-aid is all that you need. WebForms2’s approach is limited, but it should work on any browser that supports JavaScript DOM navigation.

Why does this matter to Java developers?

If you use any of the Java Web Component Frameworks (such as JSF, Tapestry, and Echo) then WebForms2 should be on your radar screen.

For example: What would be the result of mixing and matching Tapestry components and WebForms2 labels on the same page?

On a very basic level, there’s no relationship between Tapestry components and WebForms2 labels. WebForms2 is strictly client-side behavior, and won't have any effect on Tapestry’s server-side processing. The only possible collisions are between the text that Tapestry injects on the page and the labels recognized by WebForms2.

On a deeper level, for the Web Page and Web Component authors the implications of WebForms2 on Tapestry become apparent at design time.

Design of a Tapestry page begins with the creation of an HTML template. Labels are then added to HTML elements to “transform them” into Tapestry components (all HTML elements with the jwcid label are replaced by Tapestry generated output).

With WebForms2 on the scene, HTML Authors will be much more likely to incorporate WebForms2 labels within thier HTML tags. If Tapestry components don’t recognize the standard WebForms2 labels and map them properly, key information might be overlooked. If WebForms2 becomes prevalent takes off, it will make sense to re-work some of the Tapestry components.

I'm not familiar enough with writing JSF components to know if WebForms2 will have a similar impact. The "IDE centric" nature of JSF application development could very likely make any potential issues moot. Any decent IDE can easily "pick out" the WebForms2 labels when an HTML file is imported, and map this information for any JSF equivalent components.

In any case, I am pleased with WhatWG's WebForms2 proposal and approach. They have come up with a pragmatic solution (both technically and politically) for a well understood problem. Adoption of WebForms2 requires very little effort from Web Page Authors, doesn't require buy-in from browser vendors, and promotes simplified HTML authoring.

Simplifying things is good.

Continue Reading...

This work is licensed under a Creative Commons License.