The Four Classical Elements Of The Digital World: Process, Service, Event, and Information

Just as Greek philosophers tried to explain the ancient world in terms of the four classical elements of Earth, Water, Fire, and Air - with the fifth element of Aether defining the invisible context in which they exist - software architects in the digital world work in disciplines that are centered around four basic elements - Process, Service, Event, and Information. However, I think we need a "unifying theory" of the digital world that brings these four elements together more closely.

Who's The Boss?
Too often, one or another of these four elements is elevated to a dominant position in architecture, often at the expense of sufficient attention to the others. Consider:

• BPM elevates process - and is often coupled with services, as in the increasingly popular phrase "BPM with SOA." But events and information sometimes get short shrift in discussions of BPM.
• SOA elevates service - but sometimes treats process as "just another layer," events as just "something to be emitted and consumed by services," and information hardly at all.
• EDA elevates events - but often without sufficient integration into a broader view of SOA.
• Information hasn't gotten as much attention lately, although at Forrester we've been excited for some time about the potential for Information as a Service, which brings information into the SOA fold. But one still encounters "information bigots" from time to time who are throwbacks to the "data is in the center of the universe" era, or worse yet, "information laggards" who think of data as only the persistent state information for services and processes.

How to solve this problem? First, consider this evidence regarding the intimate connection between the four elements:

• BPM with SOA is indeed now the dominant trend for BPM. Forrester's survey data shows a high correlation between BPM and SOA implementations in the same shops.
• A process can also be viewed as a service, in many situations. For example, micro-processes in BPM/SOA stacks often implement a composition of multiple lower-level, fine-grained services, delivering a more business-friendly interface and information model.
• A service does indeed emit and consume events - although the significance of events is far greater than this connection. Another way to view this is that services are one of many different kinds of things that produce events, or are concerned about events arising from elsewhere.
• An event can also be viewed as information - either singly, or in groups, a la Complex Event Processing. This is particularly important to an enlightened understanding of real-time business intelligence, both as it exists today, and as it will evolve in the future.

And this really only scratches the surface of all the ways the four elements fit together and are related to one another.

One of the over-arching frameworks Forrester has created to unify other architectures is Digital Business Architecture, that subdivides our understanding of the digital world into four domains. Here's a high-level view, in a version that shows the path to follow in each domain to get from today, to this end-state:

The scope of this over-arching framework is too large for our purposes, although the four IT elements do apply here - as further articulation of all these domains, from a different perspective.

Therefore, I think we really need to develop a more explicit unifying framework for processes, services, events, and information. Do you? One problem immediately becomes apparent as Forrester works on this: how to arrange the boxes on the picture! This seemingly simple issue is really a reflection of a deeper issue - if we view these four things as architectural layers, there's not really any way to put one above the other - here's a try, which is obviously wrong:

What's the problem? Well, a process can also be viewed as a service, an event is also information, etc. Plus, you can't always say that the layer below is consumed/used by the layer above - sometimes the relationship runs in the opposite direction.

So is this a situation akin to wave/particle duality? For you non-Physics types, this is the discovery from quantum physics that light exhibits properties of both waves and particles, and so is really neither, purely - it is what it is, and sometimes it seems like a wave, and other times it seems like a particle. I think this kind of non-Newtonian way of thinking about the physical world is helpful in understanding how the four elements of the digital world relate to one another.

I recently discussed this situation with Charles Brett, a Principal Analyst on our team, and Charles suggested a circular representation, with four pie-segments, each representing one of these four key "aspects" of the digital world. Here's a shot at that:

So what  good does it do us to have this representation of the four elements of the digital world? On its own, not much. But I think it's a good starting point to help developers and architects to think about these elements in the right way. What else do we need to make this more useful? Here are some ideas:

• In the classical Greek (or Hindu) understanding of the four (or five) elements, transformation of one element into another was not an inherent part of the model, although reactions between the elements were understood to be possible. However, even after a reaction, the elements were thought to be "particular and indestructible." However, in the Chinese philosophical doctrine of Wu Xing, instead of five elements, there are five phases, Metal, Wood, Water, Fire, and Earth. And inherent in Wu Xing is the idea that both destructive and generating transformational relationships between the phases exist - hence the choice of phase instead of element to refer to them.
• Part of the detail of Wu Xing is the specification of these particular transformations that exist in the world: Wood feeds Fire, Fire creates Earth (ash), Earth bears Metal, Metal carries Water, and Water nourishes Wood. Likewise, Wood parts Earth, Earth absorbs Water, Water quenches Fire, Fire melts Metal, and Metal chops Wood.
• So a complete system of understanding built around the four elements of the digital world would also specify a complete set of relationships between them - all the specific ways in which they relate, including transformation. Without getting into why the Chinese system could be "superior" to the Greek, it's clear that we need these kinds of relationships to understand all aspects of how an event can be information, while at the same time a service is triggered by an event, as the first step in a process the event initiates.

The bottom line: I believe it is important that we develop a complete, exhaustive model - a semantic model, really - of all the ways in which the four elements of the digital world relate to one another. This in turn will fuel a complete, exhaustive meta-model for representing these concepts in systems and tools, one that can model any system in the digital world, in any architecture, in a way that can stand the test of time and not need to be changed because of some new architectural fashion.

A tall order. Do you think I'm right? Or is this a Quixotic quest? Please respond with your suggestions!

What Is More Important: Resources or Talent?

Picture this. You, the application developer, are in a big conference room. On your left is your boss. On your right are enterprise architects. Across from you are the business analysts and project managers. In the hallway is the businessperson on his "crackberry".  Why is everyone gathered here?  To discuss the next important application development initiative that the business needs to drive revenue, stay competitive, and be more efficient.

The meeting starts.

Project Manager: How many resources do we need?

Application Development Manager (turns to you and asks): How many developers do think we need?

You: 8.

Enterprise Architect: That sounds about right.

Project Manager: Ok. Great.  Now, how many business analysts do we need?

You Have Become a Victim Of Resourcification

And, so has everyone else: the project managers, business analysts, and architects. Resourcification is when all professionals are valued equally regardless of their talent or lack thereof.  We have become commoditized. We let it happen.

The Patriots Win With Talent, Not Resources

Can you ever imagine Bill Belichick, coach of the New England Patriots, talking about player "resources" like they were interchangable?  "I need two tightend resources.".  "I need a quarterback resource." No. Talent and teamwork makes winning teams. It is amazing to see how many managers are die-hard fans of high-performance sports teams but don't see the parallels in their own work.  I have been coaching my daughters' soccer team for 8 years now and it is real clear how talent and teamwork make a big difference in getting results.

Application Development Projects Need Talent, Not Resources

Smart application development professionals recognize talent. And, even though they are forced to answer the resource question, they do so keeping in mind who will be on the team. But many application development managers and project managers don't know how to even recognize talent.  This is partially due to the talent management initiatives that try to identify talent in terms of a narrow list of skills.  For example, a skill might be the ability to program in Java.  But, what does that mean?  Understanding the syntax?  Being able to describe the "static" keyword?  Or, reading Donald Knuth's 3 volume "The Art of Computer Programming" and programming the examples in Java?

Some 20+ years ago when I was a summer intern at Wang Laboratories, what was important was the ability to think, break down a problem and find creative solutions to hard problems.  When you are limited to 64K memory and have to program in Z80 assembler or PL/M these are critical abilities. We need to redefine what it means to have talent as application developers today and in the future.

What To Do At The Next Project Meeting

• If you are a project manager, ask "How much talent do we need for this project?"
• If you are an application developer and get asked about resources, stand up and then say "It depends upon what talent is available?"

Your Success In The Future Depends Upon You Not Being Commoditized

To maximize your value in the future:

• Don't let yourself become resourcified.  Make sure everyone recognizes the talents you bring to a project.  You are not a resource.
• Understand your value in the future of application development.  Some aspects of application development today will be commoditized tomorrow because of new tools and technologies that make the assembly of applications easier.  Your value lies in your ability to help create these tools and have a deep understanding of one or more business domains.

Your thoughts?

In The Mix

Hi folks,

I spent some time out at MIX in early march getting up to speed with Microsoft's latest product releases for rich Internet application (RIA) development. I thought I'd offer a few thoughts on Ray Ozzie’s keynote.

Like last year, Ray kicked off the conference by sharing Microsoft's vision of SaaS - a slightly different version from the standard view. Given Microsoft’s investments in traditional platforms it makes sense that their vision of SaaS would be of "Software AND a service" as opposed to "software AS a service”. That said, Ray articulated three ideas that are driving Microsoft's vision for development forward. I'll recap as I interpreted them from my seat in the audience:

1. Think of the Web as a hub of social and technology experiences. Ray used the term "Device mesh". It captures the idea of multiple devices used by an individual, all connected to the Web, sharing information.

My Take: I'd like that, but I think we still have a long way to go to get there. I find it's still a major pain doing something as basic as keeping my calendars in sync across my work laptop, home desktop, cell phone, XBOX 360, Wii, iPod etc. And for the near term, I've given up on my vision of a single Media PC at home driving a video on demand network. I've always liked building my own machines, and getting unencrypted HD from my cable provider on a home-built machine is just not happening.

That said, the announcement at Mix of Silverlight availability on Nokia's S60, S40 and communicator platforms was a concrete example of how ".NET anywhere" could bridge the gaps between the islands of content and data that compartmentalize my digital life. Chris Brozenik and Tamir Melamed from WeatherBug demonstrated this to me with a prototype version of their weather services running on a Nokia N95 in Silverlight. The most impressive thing from my perspective is that they managed to get a mobile Silverlight app deployed even though they've only had access to the pre-beta tools and runtime for a few weeks.

What's Your Take? Have your teams started creating a "device mesh" for your organization? What technologies are you using? Do you see different meshes for work and personal life or one integrated mesh per user? Is developing for mobile devices something that's on your radar screen? 

2. Support the power of choice in the enterprise when it comes to the cloud.  Ray spent some time talking about how he believes that the emerging utility based computing model will reshape enterprise computing, but that the way developers build software will need to be significantly refactored in order to support this transition.

My Take: I've already seen what the cloud is doing on the start-up side, so count me in as a believer. I've talked to a number of startup firms that are using Amazon's EC2 and S3 storage as the basis of their deployment model, and the thing that I find most interesting is that it allows them to significantly reduce their capital burn rate because they can scale on-demand whenever they sign a new deal instead of building out capacity in anticipation of ramping up their business. I don't see any reason why workgroups at large business couldn’t adopt the same pay-as-you-go approach to running their IT organizations - in fact, it's what some of the folks I talked to this past October at Dreamforce have already concluded.

What's Your Take? What do you think about cloud computing? Is this the start of a seismic shift in the way we deploy systems or simply the latest fad? How do you think that virtualized deployment affects the balance between a centralized or decentralized development organization?

3. Developers need to focus in on building smaller pieces that are loosely joined. With the emergence of the cloud, application design patterns are transitioning from tightly bound components to loosely coupled systems. For this transition to be successful transparency and standards are key, for Microsoft this means that they will focus on XAML, REST, and RSS on the client side and on the server side that they will invest in standards that help to virtualize the cloud.

My Take: If you project out a few years, we're going to see multicore boxes everywhere including the cloud, the desktop and quite possibly the mobile device. Coupled with better mobile bandwidth and data availability developers will need to think about creating services and widgets, and then assembling them on the fly in mash-ups, portals and social networking sites. When I look at Randy Heffner's work on the new PVS programming model, and project it onto the cloud, it seems to fit pretty well to me.

What's Your Take? Are you including SaaS as a component of your SOA strategy? How do RESTful protocols, RSS, RIAs, mash-ups and widgets fit into your development strategy? What programming frameworks are you using to achieve looser coupling of your applications?

Overall, MIX 08 was full of good sessions and technical content, which you can see here if you're interested in more detail. I even managed to get some personal tips on using Expression Blend 2.5 Beta over dessert courtesy of Scott Guthrie. We amused the rest of the table but I have to say I had a blast.

What are your thought about the emerging trends in SaaS? Are you experimenting with cloud computing or thinking about it yet?  If so drop me a line because I'd love to hear about it.

Jeffrey

The Psychology of Non-Programmers

With apologies to Gerry Weinberg, author of The Psychology of Computer Programming, what is the psychology of non-programmers, folks who would never call themselves developers, but are using new-age tools like BPM or mashups to create business solutions? I'm not sure, because although I work for Forrester now, I used to be a programmer, years ago, so I am forever cut off from knowing what it's like not to be a programmer.

Why do we care? Well if you've been following the posts to our blog, you know that non-programmers, who we might call "business developers" (although they would probably hate that term) or "super users" are a central theme in the future of application development. My colleague Mike Gualtieri has outlined two scenarios for the future of app dev, and future 2, the "Dynamic Business Developer," is all about business people who have a day job in the business, but who are also doing some of what we might call "development."

But What Do "Real Programmers" Think About "Business Developers"?

Another member of our team, John Rymer, recently gave a keynote at the Spring Experience in Florida. As part of that session John presented the vision that he and Connie Moore have developed of Dynamic Business Applications, and included some of this discussion around the role of business analysts or business developers in our vision of the future. Later on after his session, John sat down with some Java developers, avid users of the Spring framework from SpringSource (formerly known as Interface21). They said:

"I wish business managers would stop trying to micromanage our work. They should get out of the way and let us create value."

Not a very collaborative attitude, but not uncommon. Why do some developers think this way? They live in a world that values the ability to craft a better algorithm more than the ability to solve a business problem. Well, perhaps I exaggerate. I know plenty of developers who really get off on making business people happy (and I was one of them, back in the day). But the dirty little secret is that our universities and other sources of entry-level developers are still cranking out lots of this other kind of developer. Exactly the wrong kind of developer to work with the business in a collaborative fashion.

Why Are Developers So Cranky?

It takes a certain kind of person to have the concentration and focus to sit in front of a computer all day and crank out code. Some of the folks who are good at this are not so good with their social skills, nor are they really interested in the business except as a source of funds for their paycheck. Folks from this mold can make great engineers, but unless they are that rare individual who combines those qualities with great right-brain visual acuity and strong social and verbal skills, they will have a hard time communicating effectively with the business, or truly empathizing with the goals of business people.

Hey, Gene Leganza (VP and Research Director of the Enterprise Architecture team) told a funny joke the other day at our Enterprise Architecture Forum - well, it was about architects, but I think we can use it here, too:

"How can you tell when an enterprise architect is an extrovert? When he looks at your shoes while talking he's talking to you, instead of his own!"

Whoa hoh!

So What About Business Developers?

I said I wanted to talk about business developers, or non-programmers, so why so much time talking about programmers? Well, other than it being the world I know, and having that joke to tell, I think one of the key issues around growing more business developers will also be the psychology of this role, both the way business people perceive it, and the way current developers perceive it. What motivates a business person to learn how to do this work? What kind of person is good at it? Some ideas:

• Perhaps the best business developers, or non-programmers, will be similar to those folks who can craft amazing spreadsheets in Excel. I'm not one of them! But for the right person with the patience to learn how all those formulas and features work, you can do some pretty amazing things.
• Will business developers even want to be called something with "developer" in the name? Probably not! The best business developers identify much more with their business peers, than with IT folks. They don't want to be labeled a geek - whereas I fully embrace my geekhood!
• The motivation to develop in this career will have to include wanting to be a member of the club. They don't want to be a member of the programmer / geek club. So what are the attributes of the non-programmer club? Is their favorite sport more likely to be golf than cycling?

Please Give Us Your Feedback!

We'd love to hear your stories, your jokes, your ideas about business developers or non-programmers!

• Do you know a business developer, or are you one? What are they (or you) like?
• How should enterprises think about finding and growing folks like this?
• Is it crazy to think developers and non-developers can get along? What do you think these roles will look like in the future?

Thanks,
Mike Gilpin

Presidential Programming Languages

Just for fun. What if the next President of the United States of America was an application developer? What programming language would he/she use? No contemplation allowed. For each candidate, the first thing that came to mind (in alphabetical order):

 

Hillary Rodham Clinton would program in Java. Java was the hot language of the Internet boom in the 90's during Bill Clinton's presidency sometime just after Al Gore invented the Internet.  It continues to be one of the go-to development languages for new enterprise application development.

John McCain would program in Cobol. It just keeps going. Cobol is one of the most widely used language in production systems.  Chances are when you go the ATM machine or buy a sandwich at Quiznos there is some Cobol code running somewhere to support that transaction whether it is the system of record for your bank account or the logistics system that helped ship your avocados from California. 

Barack Obama would program in Ruby.  There is a lot of hope for Ruby. It is relatively new and has a loyal and growing following.  It is starting to make its way into larger organizations. From the Ruby website "A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write."  He even knows what a bubble sort is.

Ralph Nader would program in shell script.  I am not sure why.

How does all this relate to this Future of Application Development blog?  Certainly, programming languages will continue to play a role in any future scenario.  But, will the same old languages work as well in the future?  Arguably they don't even work that well now.  We are constantly writing too much code and then a new framework emerges to make our lives simpler.  I think the emergence of frameworks for programming languages actually reveal a weakness in the programming environment.

I know I haven't covered all the candidates above.  Please help me fill-in the blanks.

• What programming languages do you think the candidates will use? 
• And, if you know of some interesting new programming languages or environments that we should research, let me know.

What Is Your Future?

Everyday, you are in the trenches building apps that the business needs to be successful.  Our number one job at Forrester is to help make you better, faster and stronger.  That means helping you understand best practices, tools, technologies, architectures, platforms and methodologies that are aligned with your success imperatives.  But, it also means hypothesizing about the future of application development and especially what the future means to you.

Two future scenarios seem plausible - the incremental and the radical.  The incremental future is more of an evolutionary future where change creeps upon us slowly to meet the changing environment.  The radical future happens when the giant comet hits the earth.  There are many shades of grey in between.  Let's start with two future scenarios:

Future 1: Dynamic Application Developer Better development tools, architectures, patterns and development processes will allow app devs to design and deliver dynamic business apps.  The application development professional role remains largely unchanged, but they become more effective.  Successful application development professionals are those who are able keep up with the pace of business change and the dynamic business applications they require.

Future 2: Dynamic Business Developer A new kind of collaboration between application developers, business analysts and businesspeople will shift much of the responsibility of development to businesspeople. Businesspeople will be able to construct applications by dragging and dropping widgets, writing business rules in natural language or using other intuitive tools. Applications are developed collaboratively by businesspeople and application developers.  The role and success imperatives of application development professionals change dramatically.  Successful application development professionals are those who are best at enabling businesspeople to participate more in developing dynamic applications.

Future 1 is the incremental future - more and better of what we already have.  While Future 2, presumes a fundamental change that has been wrongly predicted many times before.  Coghead, an internet startup, is betting on Future 2 by providing businesspeople with DIY applications that use widgets and Amazon's elastic compute cloud.

Is there anything different now that makes Future 2 more likely?  Which Future is more desirable? What can you do to influence and/or prepare for the future?

Some questions for you:

1. Do you think Future 1 and Future 2 are plausible?  Do you have another potential future scenario?
2. What are the drivers that will influence the future of app dev?  Is there a comet?  If so, what does it look like?
3. What are the pre-requisites in terms of tools, technologies, architecture and methodologies needed to enable these future scenarios?

What are your thoughts?