Federated SOA definition update

Hi, I'd still like to hear your feedback on this, but wanted to update you on these definitions. Randy Heffner completed editing my report yesterday, and improved the definitions to this:

SOA interoperability is the ability of SOA services and infrastructure to work together by efficiently exchanging information at a specified quality of service level using common formats and protocols, which may be accomplished, at least in part, using mediation.

SOA federation enables diverse domains of SOA services and infrastructure to interoperate seamlessly and transparently as one by delegating among the SOA domains responsibilities such as service location, security, activation, mediation, policy enforcement, ensuring high quality-of-service (QoS), and many others.

So please respond to these new, improved versions!

Thanks,
Mike Gilpin

PS: Max, I saw your post. I think you have a good point, that done the wrong way, SOA can be too complex, and that federation can just be an effort to put lipstick on a pig (and yes, I chose that phrase on purpose!). But even in a well planned and good SOA implementation, these issues of interoperability and federation still come up.

Federated SOA - What does it mean to you?

I've been working on a major report on this topic:

Title: Building Interoperability And Federation Into Your SOA Platform Strategy

Exec Summary:

As large and heterogeneous enterprises reach greater SOA maturity, enterprise architects often find that different business areas or domains need different things from an enterprise-level SOA platform. Accommodating these requirements may require architects to segment their SOA platform strategy and build in an extra level of interoperability and federation between different SOA domains. SOA platform federation may be driven by heterogeneity of SOA infrastructure and products across domains, but can also occur in a homogeneous platform that is configured differently for each domain. Architects should separate true business requirements from accidents of history which may reflect weak architectural governance, decide which patterns of interoperability and federation are truly necessary, and then expand the SOA platform strategy to accommodate these requirements.

One of the things I needed to do in this report was define SOA federation. In researching the report (mainly by interviewing six SOA architects in IT organizations, and also a few key industry thought leaders like Marc-Thomas Schmidt at IBM, Miko Matsumura at Software AG, Hub Vandervoort at Progress Software, and some folks who worked for BEA at the time, but are no longer there), I learned that there is some overlap and confusion between the definitions of interoperability and federation. So here's what I came up with in the report, working with Randy Heffner and Larry Fulton to refine the definitions, and also taking feedback from the folks I interviewed, like Skip Snow:

SOA interoperability is the ability of SOA services and infrastructure to seamlessly work together, through the exchange of information using common formats and protocols, which may be accomplished, at least in part, using mediation.[i]

SOA federation enables multiple domains of SOA services and infrastructure to interoperate, seamlessly and transparently across an entire enterprise, by delegating among these SOA domains responsibilities such as service location, security, activation, mediation, policy enforcement, ensuring high quality-of-service (QoS), and many others.

Of course, you may need to read the whole report before you can really comment, but I'm interested, what do you think now, just based on this language? What do you know about SOA federation? And what problems have you been encountering from a lack of federation, from the Balkanization of your SOA into a bunch of SOA silos?

[i] IEEE defines interoperability as the ability of two or more systems or components to exchange information and to use the information that has been exchanged. Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries.

How do you think Technology Populism affects companies?

One week ago, I reached out to Max J. Pucher, founder of ISIS Payprus Software, to find out how he thought Technology Populism affected companies. Not only did he respond quickly, but he took the time to write an extensive blog post about his thoughts on the topic. Here are some of the highlights of his post.

First, let me tell you what Forrester defines as Technology Populism:

Forrester uses the term Technology Populism to convey that, essentially, today's software implementation inside an organization is driven by employees' individual preferences rather than that of IT departments. While this may not please IT managers, Forrester believes that instead of trying to block users, they should embrace both the rewards and the risks of Web 2.0 in the enterprise.

Although Max agrees that it is time for a change, he does not agree that this change should be called Technology Populism. He suggests that we use the term “IT User Rebellion,” which he explains to be the “dynamic, user oriented, freely customizable interfaces and functions that people find today on the Internet and in Web 2.0 applications.”

Another point he makes is that “Process must be about empowering people.” He goes onto explain that IT should give all business users the tools that they need and allow them to change and adapt the tools, resulting in a product that can be distributed successfully. He says that this is easy to do and that these systems are real — therefore, we need to open our eyes to see them.

In conclusion, Max agrees with Forrester, saying that “you will need guts to do something different and new. True innovation is being asked for.” But don’t just jump on the bandwagon — try something different.

Read Max’s full blog post defining Technology Populism.

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!

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