Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

So you've been reading the many recent articles on the Web about REST, how it's the future of Internet architecture, and you've decided to begin applying some of it in your work. But when you start digging into the subject, REST by itself seems to be about moving data resources from one place to the other over the Internet, not building complete applications. It's unclear (and certainly poorly documented) to you how to situate it properly in context; a fully realized and well-designed piece of software.

You start wondering how REST is used specifically (and strategically) in an application or overall software architecture. In other words, what are the moving parts and rules for applying them. You also wonder what else you should aware of that can be used in conjunction with or to complement REST and make it better. You might even want to know when to break the rules and use other related approaches. This is where something known as WOA becomes useful.

WOA as a complete REST architecture

This is where a deeper discussion on Internet applications and specifically, Web-Oriented Architecture (WOA) comes into the picture. WOA creates a more sophisticated and up-to-date vision for modern Web applications that aligns gracefully with the grain of the Internet. It also is generally (but of course, as with any approach, not always) true that WOA applications are easier to build, connect to other systems, and maintain for the Internet (and yes, Internet-type networks, like your enterprise intranet.)

Why is WOA generally so much better than traditional service-based architectures? Because WOA is an integrated, emergent architecture that is born out of countless lessons learned about what works and what doesn't when designing software for the Web. It's not created by a big software company, it's not a commercial piece of software, it's not a giant set of standards from a standards body.

Instead, WOA is just what developers are doing lately and more and more of it is showing up in our favorite Web application frameworks like Ruby on Rails, Django, and the nascent cloud computing platforms. In other words, it's a set of best practices for designing Web applications. And it's not a grab bag of approaches and technologies, it's actually a fairly elegant model that works: It's secure, it scales to the Web, it performs, it's all those other things that we like when we are idealized lazy programmers. WOA is also generally simple to work with, easy to implement, and usually is intuitive once you understand the Web. Note: One exception to this is REST being "the engine of hypermedia state", that certainly takes some genuine noodling over to understand. I'll see if I can tackle that in an explainable way in the near future, since it's one of the best and most important parts of REST. In the meantime, a walkthrough of Sun's RESTful Cloud API perfectly illustrates this concept.

So, in short, WOA is much more than REST and REST is the foundational architectural style for WOA.

You can see all the key elements in the diagram in the upper right of this post. It's a good start at understand what's essential about WOA (which at its core is about RESTful approaches to software) and what else you can do with it. Chances are good you'll end up using things like JSON and ATOM. Perhaps to a lesser extend things like OpenID or OAuth, though you should definitely put those on your to do list.

A more exhaustive list of things that are WOA is below. Many of them can be used in non-WOA ways (in other words, breaking RESTful principles). Don't use them that way. Instead, think about resources, links, and hypermedia and how to compose, distribute, and consume them.

The Aspects of Web-Oriented Architecture

1. Transfer Methods. This is at the core of REST and ROA and is the foundation of Web-Oriented Architecture. You can read Roy Fielding's chapter on REST (he conceived of the approach originally) or you can just follow the simple guidelines here. At other times, protocols like BitTorrent can be used if the requirements warrant it, but these are exceptional scenarios that I will cover at some point in the future.
2. Data Representation. Just about anything that HTTP can transmit can be your state representation which you can then compose, distribute, etc. XML is standard and JSON is getting more and more popular but it can even be an image or other media, though in general, the simpler the representation, the more consumable it is.
3. Data Portability. Getting your data into and out of WOA-based systems requires some support for a few standards. In particular, being a good Web citizen requires paying attention to these, even if most users or customers don't ask for it upfront. Eventually, they will want it, need it. Fortunately, these are also pretty straightforward.
4. Security. Internet security is a major and ongoing topic and securing you WOA applications requires more than just SSL, which is really the only option with HTTP that is widely recognized and universally used. SSL has also never been compromised. But user identity especially is evolving very quickly on the Web right now and open security/identity approaches like OpenID and OAuth need to be in your architectural plans these days. Both are also very WOA friendly.
5. Composition. Building applications out of REST services is a whole set of techniques in and of itself. Hypermedia is of course the core model for composition and your Web pages or other code will operate directly on resources with RESTful design principles. Mashups and and Web widgets and gadgets are important too. OpenSocial and other emerging social networking application standards (which work best as, you guessed, WOA apps) are also becoming important as well but have some potential for lock-in and their eventual success is still unclear.
6. Distribution. Getting your services out there and consumed is still an art form, but the technologies are straightforward. HTTP is of course the canonical way to access REST resources but going the full API route is the best way to get them consumed. Widgets are thus a key distribution strategy (on the push side) in addition to being a composition strategy (on the pull side).

If you on the enterprise-side of the story and wondering how this will affect you, please read my recent examination of WOA and SOA.

Update, June 8th, 2009: Dave West over on InfoQ did a good summary of this post today in REST is a style -- WOA is the architecture.

Are you creating a new Web site and developing a user registration system that requires new visitors to sign-up and create a user ID and password? Stop now and read this. There are now more effective approaches for dealing with Web accounts which are more powerful and are better for you and your users.

The concept of Web identity has recently undergone significant evolution that all Web developers and architects, both consumer and enterprise, should be readily familiar with today. These new identity options, specifically OpenID, OAuth, and Facebook Connect, when individually used can:

• Make it easier, faster, and safer for users to establish their identity on your site.
• Enable businesses to have single sign-on to your applications.
• Turn your site into a platform for 3rd party applications which can access user data safely and securely.
• Can integrate your site or application into the social experience of the user and their connections.

This post explores these three new ways to provide user identity that will make your Web applications work substantially better and make your users more secure and satisfied. There are also some important caveats and issues to be aware of and which we'll also discuss.

Backstory

One of the parts of the classic Web that's unfortunately still with us is the trusty old user ID and password combination, one per Web site. That's because the Internet itself has no intrinsic identity system built-in; anonymous access is the default and anything more sophisticated has to be cobbled together one-off for each site. This means most Web sites today implement user identity uniquely with different sign-up processes, user ID requirements (sometimes you get to pick, sometimes you have to use your e-mail address, and very often your favorite ID is already chosen, etc.) Then there are varying password length requirements if you are lucky, variable recovery processes if the password is lost, and so on. This is the challenge of an open, decentralized system (the Web) that has very little top-down design: How to provide users control and consistency in an online world where there are very few widely accepted user-centric open standards.

Interestingly, this is the one of the rare instances where enterprises got it right long before the Web and is now a relatively well-solved problem -- at least inside the firewall -- with something known as single sign-on. Often referred to as SSO and embodied by technologies such as Kerberos, smart cards like RSA's SecurID, and Windows Integrated Authentication, single-sign on ensures that users have just one single, consistent identity and sign-in credentials. Single sign-on works then seamlessly to enable them access to the various applications that they use on the network. There is only one user ID and password to remember and it can be reset, administered, or even shutdown centrally whenever required.

Note I say "easy to implement" is a requirement for Web identity systems and I should note that making user identity truly secure is one of the harder problems in software. This can mean that OpenID and OAuth require a fair amount of work to implement successfully. The good news: All three new identity approaches presented here are now fairly easy to use right out of the box since much of the hard work has been done to create libraries for the most common programming languages and environments. I will observe that it's still up to you, the designer of the Web application, to ensure these libraries are doing the right thing by your users. This is yet another reason why Web identity is still so often reimplemented over and over again; lack of trust of 3rd party code and not-invented here are still two powerful forces in software development. However, the value proposition has grown to the extent that these do-it-all-yourself positions are growing increasingly untenable.

That's not to say considerable care shouldn't be used. In general, the more important the user data your application handles, the more auditing and regular code reviews you should conduct of your security and Web identity libraries.

The identity options: OpenID, OAuth, and Facebook Connect

Each of the identity options presented here does something slightly different in terms of providing users with either their choice of login and Web identity or safe access to their data from elsewhere on the Web. As such, you will likely be faced not with choosing one of these three identity options but actually all three of them to give your users the options they what and will increasingly expect. I've highlighted in the past the number of core competencies that modern Web developers and architects have to master these days, and it's a tall order. These options add to that burden but as you'll see, provide considerable value in return.

OpenID

The best and most authoritative explanation of OpenID can be found here at OpenID Explained. It's quite simple: Let your users use the identity provider of their choice to login to your application instead of filling out an online form and capturing the information in a private, local account that users are not likely to trust nor long remember. Chances are nearly 100% that a user already has a valid OpenID from the many popular services that already allow their IDs to be used this way today. OpenID use is also growing: Recent reports show that sites offering OpenID logins are currently reporting that 10-15% of users will login this way and the average is climbing. Venture Beat also had a decidedly bullish outlook on OpenID today.

Many site have their business model and valuations wrapped around the number of registered users that they maintain. OpenID does NOT make this model go away, it merely provides an easier way to begin a relationship with new users. It even makes it easier for the user to interact with a new site. The full set of benefits for offering support for OpenID is:

• Faster and easier sign-up. Users get the choice of ID they prefer to use and can also choose how much information you get to see about them. You can still ask any necessary registration questions after they sign-up with their OpenID. Note also that field experiments have shown that the simplest possible registration process is 3 times more effective at eliciting sign-ups. OpenID naturally takes advantage of this fact and is the perfect complement to the highly effective lazy registration pattern. And don't forget that you still get to add the user to your local account database with all the information you care about, just in the context of their OpenID, meaning that you don't get to know their password or any other information they don't want to give you.
• Better sign-in process and lifecycle. Users only need to remember one user ID and password and so will always have an easier time logging in. It also places the burden of password maintenance and account support (at least some of it) on the 3rd party OpenID provider. And since the OpenID standard makes sure that passwords are used in a secure way and never passed along directly to sites that offer OpenID logins, users feel safer continuing to use new sites. As I've explored in the past, OpenID also potentially allows enterprises to extend their single sign-on experience out across the Web to SaaS applications that support OpenID.
• Consistent Web identity. There have been many discussions recently about namespaces as the new lock-in, particularly today's post from Chris Messina, and OpenID allows users take advantage of this to establish their own namespace consistently across multiple Web sites and indeed, the entire Web. When someone sees a given OpenID on a site, they'll know it's the exact same user they see on another site. Giving users the ability to unambiguously identify themselves authoritatively on your site will be seen as an increasingly important requirement of today's social Web.

To actually support OpenID, you'll need to implement the current specification or use one of the many available OpenID libraries that already does it for you. Support exists for all the common languages: C#, Java, Perl, PHP, Ruby, Python, and even Haskell. The bottom line, you'll be learning about digital signatures such as HMAC-SHA1 and extensible resource identifiers, or XRIs.

It should also be noted that the getting the user experience of OpenID right is essential for being successfully with it. Because most visitors will still be unfamiliar with it, a lot has been learned about how to offer the sign-up and sign-in experience in a way that is accessible and understandable. Early OpenID adopters often made the process too complicated or inexplicable to the user. A lot has been learned about how to do this correctly to enable the double digit usage rates we're seeing today on sites that are successful with OpenID. Probably the best presentation about effective OpenID user experiences is Brian Ellin's deck from this year's OpenID UX Summit, I encourage you to study it.

OAuth

Using a site through its user experience is now only one way in which the Web will interact with your service. If you're only offering a visual user experience and don't currently have an application programming interface, or API, you're behind the times. Open APIs are one of the most powerful new models for delivering services on the Web and they enable 3rd parties to integrate with and build on top of your product, creating all new services and mashups. This leverages something I refer to as Jakob's Law, which says that most of your traffic will ultimately be driven by external activities on other sites. Thus, more usage will often come in through an API than through the user interface. For example, Twitter famously has 10 times more usage through its API than through its Web experience, which I recently reconfirmed is still the case with Twitter's Alex Payne at Web 2.0 Expo earlier this month. It's also no accident that Twitter recently added support for OAuth.

However, the challenge with APIs is the same as with user experiences: How to let users access their data remotely in a safe way without having to give the 3rd party application their user ID and password for your site? Users might even feel comfortable giving their credentials for a Twitter application like Twitterific, but they certainly aren't going to do that for critical applications like e-mail, banking, or e-commerce. Enter OAuth, a method for allowing 3rd party applications to gain access to user data with their permission, but without having to give the credentials to that application. In other words, users can "authorize" 3rd party applications to access their data in your site, without giving that 3rd party application the user ID and credentials.

The benefits of securing your API with OAuth include:

• Safe, secure 3rd party data access. Users will be able to give permission for specific apps to access their data on your site without having to share their user ID and password with the 3rd party.
• Declarative control over 3rd party access. Users can also block the access of 3rd parties they previously authorized without having to have access to the 3rd party application. This gives them declarative control over who accesses their data and makes them more likely to use such applications.
• Greater use of 3rd party applications drives local use. For many applications, handing out user IDs and password to 3rd parties is unacceptable to users. They will only use the sites they trust. Since the APIs often become the dominant channel through which usage occurs, meaning that 3rd party sites can often represent the bulk of interaction if appropriate security controls are in place and users feel safe, OAuth can drive increases in usage and traffic.

You can find the OAuth specification here but most will opt to use one of the many pre-built libraries that is already available and which greatly simplify implementation. The language options are much the same as with OpenID which is good since OAuth is seeing broader and broader adoption as its benefits become clear and it gains critical mass.

Reconciling OpenID and OAuth

Now, those paying close attention to this discussion might notice that OpenID and OAuth seem in direct opposition. OpenID allows users to employ remote 3rd party logins and OAuth tries hard to make the local ID safely usable externally, at least when it comes to access through the API. In reality, OpenID and OAuth are an excellent combined strategy and plenty of work is underway to make it possible to use OAuth with OpenID. Sites that support this combination will use the user's preferred login for both the user experience (UX) of the site as well as for the API, creating a seamless, consistent experience. The Step 2 project has begun to "combine the OpenID authentication and the OAuth authorization protocols" and has involvement with many of the major players in the space including Joe Smarr of Plaxo and David Recordon of Six Apart.

OpenID and OAuth represent major, scalable Web identity authentication and authorization systems that work with both a user experience as increasingly popular API access methods. They are both open standards and have the backing of many major players, particularly OpenID which has the backing (though only partial implementation) from Yahoo!, Microsoft, IBM, Google, Facebook, and other influential organizations.

Facebook Connect

Open Web advocates are probably wondering why I've included the proprietary Facebook Connect in this discussion of Web identity. That's because there is as of yet no major social identity system that is open and has broad support. Consequently, I will warn you that using Facebook identity is something that should be done carefully with eyes wide open for the lock-in issues and dependencies that can result. However, the value proposition is considerable. For example, Facebook claims that for many sites "2 out of 3 new registrations come via Facebook Connect, and those users have about 50% more engagement on sites". This alone will be worth it for a great many services, and certainly thousands of services have agreed.

By social identity I'm referring to not just a user's individual identity but also their social graph, or list of connections they've established online, as well as the communication that takes place between those contacts, typically an activity stream.

Social identity is fast becoming essential context for for online applications; it's not just enough to have you as a registered user since today's Web applications also need to know who your connections are in order to provide the services they offer for communication, collaboration, etc. Social identity systems allow you to login and then be able to refer to and access your social connections and communicate with them. This is far preferable to the old-school equivalent: Importing your contact lists and then inviting all of them to the new application you're using. The days when that was acceptable are over, if they ever were. Now you can just use your social identity and they can see what you're doing in their activity stream and decide whether or not to respond or participate.

For example, I use the video sharing site Vimeo quite often but many of my friends don't and don't even have an account there. But they can see what I'm doing on Vimeo with my Facebook Connect link that shows my videos in their Facebook activity streams when I post them. They can then decide if they want to view the video or otherwise interact with Vimeo.

Facebook Connect itself is a simple set of JavaScript libraries and XML markup that allows you to enable users to connect to their Facebook accounts from within your Web application. The capabilities and advantages of Facebook Connect are:

• Single-click login. Users can log in with their Facebook identity and allow your site to access their Facebook profile.
• More engagement. Use a user's personal interests to provide more relevant information and offer customized content from friends.
• New distribution models. Users can share content and actions taken on your site with contacts back on Facebook through the activity stream and other social communication channels on Facebook.
• Direct access to Facebook. Use the APIs that have allowed more than 700,000 developers to build tens of thousands of applications.

Getting started with Facebook Connect is relatively easy and the startup guide is straightforward. The integration is very platform-agnostic and requires little implementation for basic capabilities though it does use proprietary JavaScript libraries and XML markup. To get the most out of Facebook Connect will require deeper integration however, and this will create more dependencies on how Facebook manages social data and activity information. Fortunately, most good architects will be able to create a straightforward separation of concerns and one that will allow other social identity systems to be plugged in as they emerge, especially on the open side, such as Plaxo's Open Social Graph.

While many organizations remain uncomfortable delegating any aspect of user identity to external services, the reality is that online services are invariable stronger, more robust, and more attractive to users when they do. The effort is higher however, and there are more dependencies to manage but Web identity has definitively entered a near era. Proactive companies that take advantage of what is possible today will be poised to enjoy additional growth, higher user retention, and better customer relationships.

In the last year or so, after quite a lull, the software architecture business has gotten rather exciting again. We're finally seeing major new topics emerging into the early mainstream that are potential game-changers, while at the same time a few innovations that have been hovering in the margins of the industry are starting to break out in a big way.

The big changes: The hegemony of traditional 3 and 4-tier application models, heavyweight run-time platforms, and classical service-oriented architecture that has dominated for about a decade is now literally being torn asunder by a raft of new approaches for designing and architecting applications.

These might sound like incautious words but major changes are in the air and architects are reaching out for new solutions as they encounter novel new challenges in the field. As a consequence, these new advances either address increasingly well-understood shortcomings of existing approaches or add new capabilities that we haven't generally focused on before but are becoming increasingly important. A few examples of the latter include creating reusable platforms out of applications from the outset (the open API story) or cost-effectively creating architectures that can instantly support global distribution, hundreds of terabytes of data, and tens of millions of users. There are others that we'll explore throughout this post.

These innovations are hallmarks particularly of the largest systems being built today (which are running into unique challenges due to scale, performance, or feature set) though these software advances are also moving across the spectrum of software from everyday corporate systems and Internet applications to new mobile devices and beyond, such as the emerging space of social networking applications.

Mainstays of application architecture such as the relational database model, monolithic run-times, and even deterministic behavior are being challenged by non-relational systems, cloud computing, and new pull-based systems where consistency and even data integrity sometimes take a backseat to uptime and performance.

To try to get a handle on what's happening and to explore these emerging topics, I've been doing conference talks lately about the transformation of software architecture that we're beginning to see in so many quarters these days and generally finding consensus that the exciting days of architecture are back, if they ever left. Now it's up to us to begin the lengthy process of taking many of these ideas into our organizations and integrating them into our thought processes and architectural frameworks and bringing them to bear to solve problems and provide value. As one software architect came up and asked me recently, "How do I get my organization to understand what's happening out there?" This is an attempt at addressing that question.

Here's a list of the most important new areas that software architects should be conversant in and looking at in 2009:

10 Must-Know Topics for Software Architects in 2009

1. Cloud Computing. This one is easy to cite given the amount of attention we're seeing in the blogosphere and at conferences, never mind the (considerable) number of actual users of popular cloud services such as Amazon EC2. While the term doesn't have an exact definition, it covers the gamut of utility hosting to Platform-as-a-service (PaaS). I've covered cloud computing on ZDNet in detail before and broken down the vendor space recently as well. While the economics of cloud computing can be extremely compelling and there is undoubtedly a model that will fit your particular needs, cloud computing is also ground zero for the next generation of the famous OS platform wars. Walk carefully and prototype often to get early competency in an architectural advance that will almost certainly change a great deal about the software business in the near future.
2. Non-relational databases. Tony Bain over at Read/Write Web recently asked "Is The Relational Database Doomed?" While it's far too soon to declare the demise of the workhorse relational database that's the bedrock of so many application stacks, there a large number of promising alternatives emerging. Why get rid of the traditional relational database? Certain application designs can greatly benefit from the advantages of document or resource-centric storage approaches. Performance in particular can be much higher with non-relational databases; there are often surprisingly low ceilings to the scale of relational databases, even with clustering and grid computing. And then there is abstraction impedance, which not only can create a lot more overhead when programming but also hurts run-time performance by maintaining several different representations of the data at one time during a service request. Promising non-relational solutions include CouchDB, which I'm starting to see in more and more products, as well as Amazon SimpleDB, Drizzle (from the MySql folks), Mongo, and Scalaris. While many applications will continue to get along just fine with relational databases and object-relational mapping, this is the first time that mainstream database alternatives are readily available for those that are increasingly in need of them.
3. Next-generation distributed computing. An excellent story today in the New York Times about Hadoop provides a good backdrop on this subject: New distributed computing models are moving from the lab and becoming indispensable for providing otherwise difficult to harness computing power when connected to previously unthinkable quantities of data. While traditional request-response models that are the mainstay of network-oriented computing are important, so increasingly are effective ways to process the huge amount of data that are now common in modern software systems. Watch this video interview with Mark Risher and Jay Pujara at Yahoo that discusses how Hadoop "enables them to slice through billions of messages to isolate patterns and identify spammers. They can now create new queries and get results within minutes, for problems that took hours or were considered impossible with their previous approach." While Hadoop has considerable momentum, other similar offerings include the commercial GridGain and open source Disco and there are many others.
4. Web-Oriented Architecture (WOA). I've discussed Web-Oriented Architecture on this blog now for several years and my most complete write-up is here. In short, the premise is that RESTful architectures (and the architecture stack above and around it including data representation, security, integration, composition, and distribution) are a more natural, productive, and effective way to build increasingly open and federated network-based applications. The WOA debate has raged for a while now since it became a hot topic last year but the largest network on the world has cast its vote and WOA is the way that the Web is going by and large; WOA-based applications just align better to the way the network itself inherently works. In my opinion, it is a much better way to create service-oriented architecture for almost all requirements, resulting in more supple and resilient software that is less difficult and expensive to build and maintain. For enterprises considering the move to WOA, here is good overview I did a short while back about the issues and the evolution of SOA.
5. Mashups. David Linthicum wondered today in Infoworld where the mashups have gone, clarifying that he believed they had become integral to SOA and for delivering value in enterprise architecture. In reality, while mashups are extremely common in the consumer space, to the point that it's just an every day application development activity, the tools and concepts are just now ready for prime-time in business. I've previously called mashups one of the next major new application development models and that's just what's happened. Mashups were also prominent in my Enterprise Web 2.0 Predictions for 2009 (item #7). If you're not studying mashup techniques, Michael Ogrinz's Mashup Patterns is an excellent place to start studying how they impact software architecture .
6. Open Supply Chains via APIs. I find the term open APIs, which an increasing body of evidence shows are an extremely powerful model for cross-organization SOAs, to be confusing to the layperson so I've begun calling them "open supply chains." Opening up your business in a scalable, cost-effective manner as a platform for partners to build up on is one of the most powerful business models of the 21st century. However, there seems to be a large divide between native-Web DNA companies and traditional organizations in understanding how important this is (it's increasingly mandatory in order to compete online). All evidence so far points to this as one of the most important, though potentially difficult, things to get right in your architecture. Security, governance, scalability, and ease-of-consumption are all major subject areas and our enterprise architetures and SOAs must be ready for this business strategy as more and more organizations open up. Here's my recent "state of the union" on open APIs.
7. Dynamic Languages. Though dynamic languages have been popular on the Web since Javascript and Perl first arrived on the scene, it's only been recently that it's become acceptable to develop "real" software with them. .NET and Java are still extremely compelling (and common) platforms for writing and running application code but it's dynamic languages like Ruby, Python, PHP, and now Erlang that are getting all the attention these days. Why is this? As I explored in a detailed comparison a while back, a trade-off in run-time performance has generally been found to enable a large boost in productivity by virtue of what this lets dynamic languages accomplish. It also doesn't hurt that a lot of work has gone into newer dynamic languages to make them extremely Web-friendly, which is now one of the most common use cases for any programming language. Dynamic languages have architectural trade-offs of course, like any technology, though increasingly frameworks like Rails, CakePHP, and Grails are built on top of them which bring the latest best practices and design patterns, something that is not happening as frequently with older platforms. The tipping point has arrived however, and dynamic languages are beginning to take the center stage in a significant percentage of new projects. Software architects should be prepared.
8. Social computing. Developers and software architects are often uncomfortable with social computing aspect of software systems today but Reed's Law has unequivocally demonstrated that the value of social systems is generally much higher than non-social systems. Or you could just look at the many popular applications out there that are driven by their social behavior and derive their (often enormous) value from the participation it entails. Whether this is YouTube, Facebook, Twitter, or thousands of other social applications (business and consumer both), the lesson is clear: Social architecture is an important new layer in the application stack and it I've since made it two entire quadrants of my view of Web 2.0 in the enterprise as a consequence. A List Apart has a great introduction to The Elements of Social Architecture and I've identified some of the core patterns for this in my Enterprise 2.0 mnemonic, FLATNESSES. Fnding a high-value place for social computing in our enterprise architectures will be essential for modern software efforts.
9. Crowdsourcing and peer production architectures. Increasingly, the public network (the Web) has been used to enable potent open business models that are beginning to change the way we run our businesses and institutions. This started with open source software and has since moved to media and is now encroaching on a wide variety of industries. The models for doing this online require software architectures that can support this including architectural models for harnessing collective intelligence, moderating it, aggregating it, and protecting it and the users that provide it. As I wrote a couple of months ago in 50 Essential Strategies for Creating a Successful Web 2.0 Product, these architectures of participation create most of the value in the software systems that employ them. If you're not sure this is a software architecture issue, just look at Amazon's Mechanical Turk or CrowdSound, that latter which is a widget that allows even end-users to dynamically include crowdsourcing into their applications. You can also read John Tropea's new exploration of this topic for an application layer viewpoint.
10. New Application Models. The Semantic Web seems to be on the rise again and I've already covered Platform-as-a-service and mashups here, but in addition to these we are seeing entirely new application models cropping up in scale online. Whether these are Facebook applications, next-generation mobile apps (iPhone, Android, RIM, etc), OpenSocial or just the increasing prevalence of widgets and gadgets, the trend in the atomization of software (which was done still perhaps the best and most effectively so far in Unix) is reminding us that we still have new discoveries ahead of us. While these often seem trivial, aka applications as a feature, it's also increasingly clear that these are going to be here to stay and can provide considerable point value when they're designed correctly. Certainly for next-generation intranets and portals as well as the online "desktop", micro-applications which have to contend both with scale and with being useful and secure while embedded in other applications is increasingly on the radar. Know how they work, why they are so popular (there are tens upon tens of thousands of Facebook and OpenSocial applications alone) and learn how they can be used to provide real utility and every day value.

Any list of what is new and important in software architecture must be personal perspective so I invite you to add your own below in comments.

I recently had the privilege of being on David Linthicum's excellent Real World SOA podcast show on Infoworld to talk about Web-Oriented Architecture (WOA), a topic that readers here know I've been exploring for a while now. David's one of the most respected names in enterprise architecture and SOA and so I enjoyed the opportunity to discuss with him what's happening to SOA as it meets the Web and begins to evolve in new and interesting directions. We had a lively conversation that covered the gamut from innovation and enterprise mashups to open Web APIs and cloud computing.

A full transcript with links is provided lower down in this post. You can also listen to it interactively with the Web widget below, or you can download the the entire mp3 file of the Real World SOA Podcast episode on WOA.

Note: I created this transcript from the mp3 file using the terrific CastingWords service which is a WOA application that offers its transcription service by building on top of Amazon's innovative Mechanical Turk API.

Powered by Podbean.com

David Linthicum and Dion Hinchcliffe discuss WOA in September, 2008

It's been an interesting few months in the enterprise architecture space as we look at where service-oriented architecture (SOA) is headed this year. I wrote a detailed exploration of this on ZDNet last April and the discussion since then has only become deeper and more urgent. Getting general consensus on a new acronym is always a difficult thing to get widespread traction on, much less a new architectural approach. I'm not personally caught up on what we call this next generation of lightweight, Web-aligned SOA either, but WOA is the best name I've seen so far.

With the WOA discussion it's also been clear that the SOA industry -- vendors and practitioners alike -- are protecting their turf and looking a little skeptically at something that has the potential to change the center of gravity in the SOA business. I think there is actually little threat here; most of the top-down activities that SOA initiatives have been putting in place, such as governance and cross-functional business architecture alignment, are just as appropriate -- if not more so -- when it comes to making WOA successful. We'll talk a little bit more later about SOA products.

And let's be clear here: WOA is a really a sub-style of SOA that is actually highly complimentary. I personally believe we've collectively discovered that we've been spending the last few years on a course that just needs a healthy and appropriate re-adjustment, with the concepts in WOA helping us find a better way.

WOA clearly offers a number of advantages to those doing traditional SOA today. This includes considerably improved service consumption models that are less expensive and time consuming to use as well as unleashing the tremendous power of link architecture to drive information discovery, leverage, and analysis. The profound business implications of open APIs and cloud computing are growing clearer by the week. WOA also provides an excellent on-ramp to access the many powerful new online product distribution models currently available today. Distribution of SOA is a woefully neglected topic and WOA can bring an extensive set of techniques, from syndication to extraordinarily low-impedance Web services.

For its own part, the term WOA itself goes well beyond the simple reconciliation of Web services technology from a SOAP-based model to one based on REST. For this very important reason, WOA is not synonymous with REST. WOA encompasses all the architectural issues that are drive by the design of the World-Wide Web, an architecture, I will point out that has continued to refine itself including the rise of open Web APIs), prepackaged service consumption mini-applications (aka widgets or gadgets in the Web world, the advent of JSON, browser-based mashups, the recent resurgence of the Semantic Web, and much more. So, hopefully to put the REST/ROA vs. WOA debate to bed; REST remains an absolutely core architectural element, but WOA by definition encompasses the full architecture of the Web today.

The Web also clearly includes the browser and it's the browser itself that has driven many of recent innovations and trends in WOA, particularly mashups and the interest in JSON. And when it comes to the enterprise space, the reason that WOA has become such a significant topic is for the reason I gave in my most recent sum-up of WOA:

"It’s important to remember that no small system can sustain contact with a large system for very long without being fundamentally changed by it. This is what is happening with businesses (the small system, no matter how large) and the Web today (the big system.) The intrinsic nature of the Web is driving major changes in how we create network-based products and services and is inexorably turning us into Web-oriented businesses. Businesses that want to be successful on this network without understanding its fundamental nature and capabilities are only delaying the time it takes to reach the full potential the Web offers."

Unfortunately, technology always moves faster than businesses can adapt, and the situation hasn't gotten any better, quite the opposite. Fortunately, the on-ramp to WOA for most organizations should be far less traumatic that many systemic shifts in the past, such as the one from structured systems to object-orientation. Even more helpful for enterprises looking to start down the WOA