the philosophical architect

Windows 7 + Surface + Interknowlogy == Healthcare Innovation

CurtD — Tue, 03 Nov 2009 17:23:01 GMT

Here’s a Zen question: When does data become information? Is it when data is collected in some normalized form? Is it when some data can be related or correlated to other data in a well defined way? Or, is it only when it finally gets consumed by an application, crunched by business logic and finally presented to the end user in some structured context? I would argue some or all of these are necessary, but not sufficient. Data only truly becomes information when it informs. Digital data has to make that inductive leap from a digital device to the human perceptual apparatus, traverse the neural pathways and get synthesized by the brain. It’s only when someone experiences that cognitive “aha!” moment that we commonly refer to as knowledge or understanding.

And if so, collaboration only becomes possible when we can share context and information with each other. It’s not just about data. This is why user experience and presentation is a profoundly important aspect of information architecture. (If you’re not convinced on this point, treat yourself to some of Edward Tufte’s work. I find him far more convincing than I on this subject.) Even when information is available, however, distance in space and time remains as an obvious obstacles to human collaboration. Computers and networks can help overcome this obstacle—but only if the platform and application are up to the task. Just moving data from one place to another is not a solution. Let’s take health information as a concrete example.

One of the most important and fastest growing forms of electronic medical records (EMR) today is image data created from a growing variety of radiology devices. X-Rays, CT Scans, MRI, PET Scans, Ultrasound and others are producing an explosion of digital imagery in 2D, 3D and yes, recently even 4D. For example, if you have never heard of fMRI think of 3D time lapse photography for the brain; one that can show the flow of blood in the brain over time. Such images can be incredibly powerful medical tools--not only for diagnosis, but non-invasive screening, groundbreaking discovery, research, and especially collaboration.

Of course, the sheer size and complexity of such data create challenges up and down the technology stack including storage, searching, network transport, processing, and presentation. All of these challenges are relevant for collaboration over these images. But has this explosion in image data set off an explosion of information?

Recently, however, Interknowlogy has demonstrated what can happen if we address these challenges. Using both Microsoft Surface and Windows 7 multi-touch, this team has shown that completely interactive remote collaboration in real time with medical imagery is possible now. To see for yourself what is possible in this space you should check out this demo by Interknowlogy. [The video is large so it takes a few minutes to download but trust me—it’s worth the wait.]

The Interknowlogy team has demonstrated that natural user interface (NUI) technology like multi-touch can support and enhance collaboration between users who are local or remote to one another. The ability to make annotations (telestration) on the fly is almost gratuitous. Wow! They have also demonstrated that this can be achieved across different form factors, using Surface devices and Windows 7 on a HP TouchSmart device. Given that Silverlight 3 supports multi-touch today, it is just a matter of time before some of this collaboration is possible in the browser.

To see something truly wondrous in all this, look beyond the wow factor for a moment. Anyone who has had the experience of helping a friend or relative manage a very serious illness may have had the frustrating experience of having to pick up a DVD with one of these images from one medical specialist and drive miles to deliver it to another medical specialist over the proverbial sneaker-net. Now, just imagine a world where your primary care physician, radiologists and other medical specialists could consult and collaborate with one another immediately, and form a plan of action from anywhere in the world. This marvelous vision is much closer than you think!

From S+S Architecture to Azure

CurtD — Wed, 28 Oct 2009 18:04:58 GMT

One of the obvious attractions of the Software-plus-Services approach is that it can provide a best-of-both-worlds way to deliver great software value. On the client-side, you can offer a rich user experience, the right balance between ease-of-deployment and use of desktop capabilities, and a comfortable level of trust and security for each application. At the same time, you can delegate complexity or intense computational workloads, or stringent scalability and availability requirements to powerful services in the cloud. These benefits seem pretty compelling, but where will those powerful services actually live?

This question is especially pressing for small- and medium-sized organizations who must work within budgetary constraints and/or more limited IT capabilities. The question may also be urgently important for anyone who wants to provide powerful and complex services and make them easily accessible to less savvy users or users with diminished capacities. In these situations, S+S can be a very potent model if there is a manageable and affordable place to house those services. Perhaps the unspoken promise of those who have already embraced this model is that it will be possible, and hopefully a little easier, to exploit the Windows Azure platform.

If S+S helps you to be Azure-ready, there should be concrete evidence of that—and there is! Over the last year of so, I have had the opportunity to work with ITNAmerica who is in the process of furnishing just such evidence. ITNAmerica is a non-profit organization with a very important and truly unique social mission. It provides dignified transportation options for seniors. As the baby boomers approach retirement age, the social need for these services is growing rapidly and ITNAmerica must keep pace. Workloads grow in a stair step fashion as each new affiliate is brought onboard.

As you can imagine, this growth pattern creates some fairly extreme technical challenges; challenges which are vital to supporting this important social mission. Software must be available to each local affiliate that is easy-to-use and that does not require sophisticated IT capabilities. ITNAmerica also has to provide core services to each local affiliate, such as scheduling rides, on-boarding seniors who need rides, and the volunteers who can provide them, tracking special needs of seniors who may have diminished capacities; not to mention a sophisticated scheduling engine for coordinating all this. These challenges are compounded by truly mission critical architectural requirements. If these services aren’t reliable 7 x 24, the consequences may be life threatening. Moreover, the growth of the local affiliate network creates capacity and scaling requirements that would give the most seasoned CIO some new gray hairs.

ITNAmerica saw fairly early in the game, that an S+S approach could help meet some of these challenges. They are currently rolling out a new version of the ITNRides system based on an S+S model—even while on-boarding their newest local affiliate in Cincinnati-- and this has helped enormously, but big challenges still exist. Take a look:

ITNAmerica must build and host some very complex technology and they have to do this all within the constraints of a non-profit IT budget. An S+S architecture alone does not ensure that these core services can be hosted, managed, and monitored in an efficient and affordable way. Traditional hosting services do not provide the platform and underlying services that will make this possible. Initially, ITNAmerica has had to create its own private little cloud to host its core services. But this can quickly become prohibitively expensive to manage regardless of whether services are hosted on-premise or off.

This is where Windows Azure can help. By embracing an S+S architecture ITNAmerica is in a good position to begin to migrating some of their core services into the Azure cloud environment where it will be easier to meet some of these challenges. Since the ITNAmerica services are already implemented on .NET, SQL Server 2008 and Windows Server 2008, the transition to an Azure infrastructure will not require radical redesign. Instead, it will make their transition into Azure smoother, reduce much of the cost of maintaining a private cloud, and leverage the efficiencies of Azure.

My take away from this story is that S+S and Windows Azure are proving to be a potent combination because, together, they are enabling innovative new business models. These models have proven technically difficult or impossible with more traditional, Web 1.0 approaches—at any price. As in the case of ITNAmerica, some of this innovation is being pioneered by small, nimble, forward thinking organizations. To the extent that this innovation is empowered by S+S and Azure, and it addresses a pervasive and pressing social issue that we all face sooner or later; I think it gives everyone something to stand up and cheer about. Go ITNAmerica!

CardSpace De-Mystified at OWASP in Hartford

CurtD — Tue, 10 Jun 2008 18:27:51 GMT

If you are interested in security, identity management, and web standards; you won't want to miss the next meeting of the local chapter of the Open Web Application Security Project (OWASP) in Hartford tomorrow night. The local chapter holds bi-monthly meetings on topics of interest in this space. OWASP is a community dedicated to promoting the development of secure code and supports the education of not only security architects, but developers.

At tomorrow night's meeting, Chris Winn, a Strategic Security Advisor at Microsoft, will be talking about CardSpace and de-mystifying it a bit. Chris will be touching on several fundamental concepts in the CardSpace..well.space and how it can help exert control of digital identity management in the enterprise and on the web. He'll be touching on:

. Using Infocards instead of usernames and passwords

. Identity Providers

. How CardSpace users can help users gain control over their own digital identity

.CardSpace and open, interoperable standards.

If this sounds interesting, you should consider becoming a member of OWASP and joining us tomorrow night. I'll be there, so please come and take a moment to introduce yourself. Here's home page for OWASP and the logistics for the meeting:

Agenda: Wednesday, June 11th 2008

. FOOD & NETWORKING: 5:30 - 5:45 PM

. OPENING REMARKS: 5:45 - 6:00 PM James McGovern, Chapter Lead

. CARDSPACE AND USER CENTRIC IDENTITY: 6:00 - 6:45 PM Chris Winn, Security Evangelist, Microsoft

. IDENTITY GOVERNANCE FRAMEWORK: 6:45 - 7:30 PM Prateek Mishra, Product Manager, Oracle

. Q&A and Raffles: 7:30 - 7:45 PM We will be raffling a Microsoft Zune Player, Apparel and Books

For more Information: http://www.owasp.org/index.php/Hartford

CardSpace and ADFS2-Industrial Strength Digital Identity Management

CurtD — Fri, 14 Mar 2008 21:14:52 GMT

Hey! CardSpace is not just a consumer technology. If you think it is, you're missing the point. It is a bit frustrating to hear even some of my Microsoft colleagues refer to CardSpace as though it belongs on the shelf somewhere between Zune and Halo3. So if you're one of those people running around spouting the idea that CardSpace is only important for Joe and Mary Dinnerpail; knock it off! You're simply incorrect at the top of your lungs. On the other hand, if you are interested in finding out why this technology is so important for non-consumer scenarios, you may want to keep reading.

Yes, CardSpace is incredibly valuable to consumers because it can help protect online privacy, putting the control of digital identity back where it belongs-in the hands of the web user. It will help prevent less savvy users from inadvertently revealing passwords and other sensitive personal information to phishing scams. It is a powerful preventative for identity theft and helps eliminate many of the worst aspects of password-based authentication on the Internet. True, all of this is pure goodness for consumers, but if you stop and think about it for a moment, these benefits are just as important to businesses, institutions and government organizations of the small, medium or large variety.

CardSpace is actually an extremely important first step for any person or organization with an interest in conducting secure transactions via the Internet. This includes business-to-business (B2B) and business-to-employee (B2E) every bit as much as business-to-consumer (B2C) scenarios. Notice that there is no 'C' in B2B or B2E? These scenarios were important design centers for CardSpace right from the beginning. Moreover, CardSpace is based upon the widely embraced family of open, industrial strength standards referred to as WS-*, meaning WS-Federation and WS-Trust, among others. Most importantly of all, there are intense forces at work in a wide range of industries scenarios driving the need for secure, federated transactions between separate organizations.

An Industry Scenario

To see why, take a look at the scenario I bumped into recently in the insurance industry. As anyone who has purchased insurance knows, many products are sold and sometimes managed by independent insurance agents. For these products, the industry is not simply a collection of large, competing carriers; it's an ecosystem of inter-dependent organizations. In order for the ecosystem to flourish and operate efficiently, independent agents need to access any number of electronic resources from carriers who offer these policies. Many other processes, such as first notice of loss, claims, and adjustment may require similar access to resources and applications at various carriers.

Like many other industries, important segments of insurance depend upon secure interactions with the independent agents, experts and professionals from other organizations. It's often highly impractical to manage the identities of these non-employees as though they were internal members of your own organization. Yet at the same time, providing direct access to internal resources or applications can really streamline core business processes-if this access is secure. But this many-to-many relationship creates vulnerabilities similar to those found in the online consumer world.

The Trouble with Passwords

Authentication mechanisms designed to facilitate access to internal resources are typically based on a simple username and password encrypted over an (SSL) channel. Like most people, agents that need to logon to multiple carrier sites will avoid password fatigue by using the same password for every site. This is where the many-to-many vulnerabilities quietly creep into the picture.

Imagine that the digital identity of one of these agents has been compromised by a clever phishing scam. Then ask yourself who is vulnerable. In many cases, every system the agent has access to, at every carrier the agent does business with, would then be vulnerable to fraud. There is no consumer in this picture, but the problem that the industry is facing is very much the same as the one consumers face. If fraud does occur, the credibility of the agent (and perhaps the agency) may be at risk as well, even though his or her only mistake was to be deceived by one of the increasingly slick, sophisticated, and highly targeted phishing scams proliferating on the web. To make matters worse, a conscientious agent who realizes her mistake will have an enormous uphill battle to notify all vulnerable parties and remedy the situation because so many different accounts are involved.

The trouble with passwords, no matter how strong they are, is that they are highly fungible from site to site. The same password can be used at many sites. Once compromised, every site where a particular password has been used is automatically compromised as well. CardSpace directly addresses this problem by using tokens that are not fungible at all. Instead of using an ordinary password, the user is actually sending a cryptographically sealed token that is only accessible to one party, the party that supplied the proper certificate (key) i.e the party it was intended for. This is incredibly important because it means a site can securely identify the user, and the user can strongly identify the site. When passwords are used instead of a CardSpace tokens, it is very difficult for users to be certain who they are actually dealing with. Phishing sites are counting on this to perpetrate their deception. My point about this is that many industries are just as vulnerable to these scans as consumers are, but they CardSpace provides a powerful weapon that is already available for combating this problem in industry as well as consumer settings.

Being Kim Cameron

If you want to see the big picture about identity on the Internet, you have to be Kim Cameron (because John Malkovich hasn't had much to say on this subject). If you haven't read his blog on THE LAWS OF IDENTITY, you should do yourself a favor. It's certainly the best thing I've read on this subject. The insurance industry scenario I described a moment ago is just one of many in what is referred to as the 'identity ecology'.

Kim Cameron makes a compelling case for the development of an identity metasystem for the Internet. The root problem is that the Internet was born without any identity system at all. As a result, the need to conduct secure transactions via the web has spawned a patchwork of different proprietary systems of very variable strength that users have no means to assess. Cameron points out that in absence of a standards-based identity metatsystem on the Internet, we are left with patchwork of password-based systems like the ones we have described a moment ago. Such systems make it difficult, if not possible, for users to exercise control over their own identities. Control over one's identity means the ability to control what personal information is given and to whom. In a word, the identity ecosystem is a very fragile one at the moment and it is becoming weaker as each new scheme for identity theft and fraud further erodes trust. This is a problem for consumers, but it is also a problem for specific industries as well. And, in the industry case, it will require a solution forged by industry consensus.

CardSpace is a major contribution to an open, standards-based identity metasystem, strengthening the identity ecosystem in a way that fully respects the laws of identity. I'll spare you a detailed mapping of laws to features, but I do want to call out the importance of CardSpace support for law number six: Pluralism of Operators and Technologies. With CardSpace, Microsoft has demonstrated its commitment to pluralism and open standards in several important ways, including the recently announced collaboration to support CardSpace/OpenID interoperation. In addition, Nigel Watling and the CardSpace team have demo-ed an open source implementations that uses CardSpace Infocards on other platforms. Check it out. This demonstrates the commitment to the pluralism that will be essential to a successfully address identity and security across many platform, technology and organizational boundaries.

Enter ADFS2-another Piece of the Puzzle

If CardSpace has so much to offer, you may be wondering why isn't more pervasive by now. It's a good question and there are a number of good reasons. First, there is a chicken and egg phenomenon happening here. Sites don't take the trouble to support it because it isn't widely used. Web users don't widely use it because very few sites support it at the moment. This problem will work itself out over time, but there other issues.

CardSpace is definitely an industrial strength solution, but it isn't really a complete solution for a full-blown identity metasystem. Perhaps the missing piece of the puzzle isn't obvious for those still laboring under the misconception that CardSpace is just for consumers-but it is actually a very important piece for all the B2X scenarios. Average consumers aren't members of an LDAP domain such as Active Directory. For them, the Windows Vista desktop acts as the identity provider and affords them many of the protections mentioned earlier. However, even for consumers, this can be inconvenient at times if someone wants to use an existing Infocard from a location where they don't have access to their own PC. But for many B2B scenarios, what is really needed is a highly scalable, widely trusted set of identity providers (IP) that can provide CardSpace tokens in the cloud. Among other things, this would make Infocard information available anywhere-without requiring users to relinquish control over what information they provide or to whom they provided it.

I use the phrase 'set of identity providers' to re-emphasize the notion of a pluralism of operators. This idea is intrinsic to the metasystem. Pluralism makes the idea of a metasystem very different than the Windows Live ID system today, though Live ID could certainly become one IP among others. Building a mega security token service (IP-STS) in the cloud is a major undertaking. Moreover, services such as Live ID will not suffice for a number of important industry scenarios. Highly capable, but specialized IPs.will also be needed to support industry specific scenarios. If we return to the independent insurance agent scenario for a moment, it is obvious that insurance carriers have a compelling mutual interest in securely authenticating (identifying) agents. But carriers also have a compelling interest in validating other information about agents such as whether an independent sales agent has the proper industry credentials required to broker certain types of policies.

In the language of security tokens, this information is referred to as "claims"( or sometimes assertions). It is unfortunate that this term has an overloaded meaning in the insurance business, but I prefer it nonetheless, because 'claim' carriers some of the same connotations for both meanings. A claim carries the connotation of something that must be verified or validated before it can be trusted as legitimate. So insurance, like many others, has a compelling interest in the ability t represent and validate information in the form of electronic claims about independent agents who conduct transactions with them. General identity providers like Live ID are unlikely to specialize in providing these types of industry-specific security claims .

In addition to this scenario, many organizations are seeking to federate with one another, so that employees from either company can access resource at the other. In insurance, perhaps subrogation is a good example, because employees may need to securely share documents with one another in order to reach a mutually acceptable settlement. Of course, similar patterns are evident in many other industries as well. For this type of B2B scenario, most companies will want to leverage their existing investments in identity management.

Within insurance, for example, Active Directory is fairly pervasive. Many companies will want to use this identity information when employees are conducting business on behalf of the company. To do this, a company will need their own STS that integrates Active Directory so that they can provide identity information in the form of security token claims. You can think of this as an electronic identity "badge" issued from one company and trusted by another. A Relying Party security token service (RP-STS) is needed; ideally, one that can also integrate transparently with industry IP-STS services. These requirements put us well beyond the general capabilities of desktop or generic IP-STS like Live ID.

For these situations, Microsoft is developing new technology that will be another very important step for conducting secure transactions via the Internet. The next generation of ADFS (let's call it ADFS2 for now) will be an industrial strength foundation for implementing a claims-based security token services (STS). ADFS2 will alleviate the need to build a standards-based token service from the ground up. Among others, it will provide two very important pieces of the digital identity metasystem puzzle. First, like ADFS today, it will directly integrate with Active Directory. This will allow employees of one organization to use an Infocard that contains their internal identity information. It will also allow members of the ecosystem to evaluate the trustworthiness of claims tokens issued by other members of the ecosystem. Secondly, ADFSv2 will integrate directly with CardSpace, eliminating many of the dangers of federation based upon passwords as we described above. ADFS2 will not only help to build a more complete metasystem, it will allow companies who already invested in Active Directory to leverage that investment of federated, B2B transactions.

The Industry Dilemma

In order for specialized, industry-specific IPs to emerge, demand for such services must be generated. In short, organizations must demonstrate their willingness to consume identity tokens from external identity providers. But they will hardly be willing to invest in the technology to consume tokens if there are no providers. The chicken and egg problem rears its ugly head once again. This, too, will work itself out in time because the drivers for an industry solution are strong. But there are still other issues.

A clear business model for trusted IPs must also be worked out. Different industries may require very different business models. Without one, highly robust IP-STS services may be slow to emerge. In addition, there are questions of legal liability. Who is at risk and who is legally liable if a false claim is issued? Will it be users, providers, or relying parties? None of these issues are insurmountable. Arguably, overall risk is considerably reduced by a more secure system. And finally, enterprise and industry architects must play an active part in helping to shape and refine standard protocols that are absolutely essential to realize a genuine identity metasystem.

I point out these issuesto highlight the need for interested parties within each industry to come together and work these problems out in concert with one another. If industry leaders do so, it can only help to accelerate a solution to the mutual satisfaction and benefit of all concerned parties.

Unum Harnesses SOA for Customer-Oriented Services

CurtD — Sat, 26 Jan 2008 00:37:43 GMT

The potential benefits of SOA in the enterprise can be great, including reduced cost, better business efficiency and agility, and perhaps most importantly-a much better customer experience. Unum, one of the companies I have recently become acquainted with, saw the opportunity to transform and improve the customer experience and streamline back office operations at the same time. Two years ago, Unum (formerly UnumProvident) embarked on an effort to do just that. They call this ongoing effort Simply Unum and it has begun to bear fruit.

Naturally, the technology and architectural changes needed to empower this kind of business transformation are a lot to get your arms around. Unum faced many of the classic challenges associated with taking tightly-coupled, product-centric systems, organized in silos by lines-of business and transforming them into loosely-coupled, customer-centric set of services and automated business processes. As you can guess, change of this magnitude is never simple, quick or easy. The costs and risks can be substantial. To be successful, I think service-orientation requires a fundamental cultural shift at all levels of the business -Unum definitely seems to have it going on.

The good news is that Tim Fitzgerald and Keith Stackhouse, two members of the architecture team at Unum, are willing to tell us a bit about what they are doing and how they are doing it. They will be presenting at the upcoming 6th Annual Microsoft Financial Services Developer Conference. The technical team is currently in the process of assessing their existing SOA capabilities and defining the future architectural roadmap on this basis. One of the conceptual tools Unum will be using for this assessment is the SOA maturity model (SOAMM). Regardless of whether you are just getting your feet wet with SOA or whether you well on your way and facing some of the service management issues that come with a more mature catalog of services, I think you will find this presentation well worth your while.

As a tool, SOAMM can play different roles depending upon how far along the road to SOA you are at the moment. In the early stages it can provide a vital roadmap to maturity; later on it can provide a valuable assessment tool. There are other maturity models out there, but most seem to share a focus on capabilities. In SOAMM, for example, extensibility, supportability, repeatability and reusability are measured to determine where good maturity has been reached and where there is more work to be done. To me, however, these technical capabilities-though very important-are really secondary.

Traceability is the master capability and the gold standard of maturity. At the end of the day, all technical capabilities must be directly traceable to specific business needs and capabilities. The best measure of maturity for SOA is the extent to which the technical capabilities of SOA empower the business. That's what impresses me about Unum; they took this approach from the start. The business sponsors and the technical team have strong alignment on the ultimate objectives of Simply Unum: making it easier for customers to do business with them. I'm looking forward to learning more about how they have achieved success so far and how they plan to continue their success in the future.

In case I haven't made myself clear, I am indeed saying that SOA can enable better customer relationships and better customer experience (UX)-when it's done well. The whizz-bang features in WPF are great, but it doesn't have a monopoly on UX. Very often, services turn out to be a vital organ for great UX. The folks at Unum seem to really get this. My first acquaintance at Unum was Rick Klausner. Rick's official title there is VP of Customer Capabilities and Enterprise Architecture. That's a big title and a big responsibility, but I also think its emblematic of the whole approach for Simply Unum. Customer capabilities first, enterprise architecture second; but the two linked at the hip. When the latter is traceable to the former, you have a good formula for success.

If you can make it to the Developers Conference, I think this is a session you won't want to miss.

Authorization Claims and Stable Data

CurtD — Mon, 10 Sep 2007 20:05:00 GMT

I spend quite a bit of time thinking about authorization-especially as it pertains to highly distributed computing environments. Authorization gets tricky fast in this environment. Federated scenarios are an excellent case in point. For example, Mary is a doctor in one hospital and she needs to access patient records in another hospital. Not only will she have to be authenticated, Mary will have to be authorized for those specific medical records. Services in the cloud (SaaS) will almost always require the service host to extend this type of limited trust to its bona fide service consumers. Consensus is forming about how to do this. Both authentication and authorization in highly distributed scenarios can be implemented using claims-based assertions in the form of tokens. Token standards (and services) are emerging and converging. Both SAML and WS-Authorization standards are now in the hands of OASIS and will probably be merged.

These token specifications are quite rich and absolutely necessary for building secure interoperable services, but they may not be sufficient. To see why, you have to understand the need for stable data. Keep in mind that at some level claims are themselves just data. Pat Helland has given a lot of thought to what happens when persistent data becomes a message and vice versa in the midst of SOA. Check out Data on the Outside vs. Data on the Inside if you haven't already.

Helland defines stable data as data that is unambiguous throughout space and time. You stabilize data by defining when and where it is valid. As it turn out, this concept is very important for authorization claims. Once you commit to sending messages and receiving messages that contain authorizing claims, you had better commit to defining and assessing when and where these claims are valid as well. Without such definition, authorization claims will infer far greater extension in space and or time than may have been originally intended. Let's suppose that Mary's medical credentials were revoked a moment after she sent her request messages to view various patient records at other hospitals? Those messages might be invalid by the time that they arrive-might they not? You might answer this question by saying that the request is valid as long as it was valid at the time it was initiated; but denying the problem won't may it go away. The problem with services (especially in the cloud) is that response latency (time) is generally undefined and frequently indefinable.

As I said earlier, faced with meeting business and regulatory policy demands in this environment can be tricky. Even if you knew when and where each of Mary's requests were sent, revoking them after the fact is still nearly impossible once the proverbial train has left the station. For example, there is no practical way to ensure that the revocation message can or will be processed before Mary's request; just as there is no practical way to know how long it will take to process a given request. This is why it's better to stabilize claims before they go out the door and check them as soon as they arrive.

Don't be misled into thinking that it's only the request that must be stabilized. Each claim (and perhaps each claim set) may have a different extent in space and time. In fact, that may be required in order to implement certain access control policies for individuals who have multiple roles. To use some spatial examples, Mary's medical credentials have been revoked in one state but they are still valid in another. My driver's license may still be valid even though the registration on my car has expired. When claims are constructed in one domain, it's often almost impossible to anticipate how they will be evaluated in another. In fact, making assumptions about implementation beyond what is expressed in the service contract violates the idea of loose coupling inherent in the SOA model. This is where it's going to get tricky.

If you look at the SAML specification for a moment, you will see that it makes provision for defining extent in time (as well as other conditions). As part of a claim, you can supply values for NotBefore and NotOnOrAfter . These attributes of the Conditions element are optional, of course, as they should be to provide the flexibility to handle simple cases simply and more complex cases at all. But the formal specification isn't normative; it can only take you so far. Beyond that, the burden is on us to devise policies that comply with business, industry and regulatory requirements and then implement services and consumers with access controls that effectively support those policies. WS-Policy can help us express and advertise these in the services we build, but it won't drive agreement about the substance and specific constraints of access control policies. I'm suggesting that, while bounding access control conditions in space and time are optional in the specifications, they will often be mandatory for authorization claims when sensitive information is being exchanged. We will need to stabilize claims just as we need to stabilize other forms of data in highly distributed scenarios.

Stabilizing claims can help to solve the problem of revocation. By freshness-dating claims before they go out the door-as long as we also then evaluate the boundaries of these claims when we authorize a service request. Freshness dating milk only helps if you actually check the label before you drink it. Admittedly, doing this will complicate our claims-based authorization mechanisms, but as Einstein pointed out, we should keep things as simple as possible, but not simpler. Things could get further complicated for services that are subject to strict regulatory compliance or that deal with highly sensitive information. In these cases, we will need to forge agreement between service-providers and service-consumers regarding what constitutes adequate and reasonable tolerances for claims conditions-especially with respect to time. Token specifications appear to be rich enough to support such policy agreement, but they will be no help for defining the terms.

MSIT Eats Microsoft Dog Food and Thrives

CurtD — Fri, 03 Aug 2007 01:37:00 GMT

Recently, I had an opportunity to meet several of the enterprise architects from Microsoft IT. After I published my article on Enterprise Authorization Strategy, I got to talking with Aaron Hanks about some of the challenges of enterprise authorization. Aaron has weighty architectural responsibilities addressing many of these challenges at MSIT. Last week, I spoke at TechReady5 and I had the opportunity to meet Gabriel Morgan and Nick Malik while I was out there in Seattle. They are also enterprise architects, and fellow denizens in Aaron’s building. Gabriel focuses on SaaS and Nick tends to focus on SOA in MSIT. After meeting them, I got to thinking; you have to count this pack among the big dogs in enterprise architecture. Putting aside some of the most complex enterprise requirements they face for a moment, they have to eat more Microsoft dog food than just about anybody.

In case you’re not familiar with the term, dog food comes from the expression ‘eating your own dog food’ and refers to the act of using your own software, technology and solutions in-house. Of course, at Microsoft that often means pre-released dog food, too. In the local vernacular you can use it as a verb too. As in “you should dogfood this before you release it.” As you can guess, MSIT eats a lot of dog food.

There is architectural dog food too. It’s one thing to tout the virtues of SOA, SOI, SaaS, S+S and other sibilant acronyms on the lofty pages of MSDN; it’s quite another to actually solve real-world, day-to-day problems with this architectural approach, knowing that your company’s success depends upon it—in more ways than one. To me, MSIT is one place where the rubber has to meet the road. The requirements of governance, discovery, shared data schema, scalability, master data management and application portfolio management, for example, aren’t just theoretical exercises for architects at MSIT; they’re concrete issues that have to be addressed with practical solutions that work today. You have to respect that. I do, anyway.

Btw, if you think MSIT is just a downstream consumer in the dog food chain, you would be wrong about that. When these dogs get hungry, they have been known to aggressively bare their requirements. If an enterprise requirement cannot be fully met with an existing product or technology, MSIT is frequently first to experience the agita. When they drive these requirements back upstream to the product groups, they are effectively acting as a proxy for many of Microsoft’s enterprise customers who are facing similar challenges as well as for those of us in the field who work with these customers.

You shouldn’t kid yourself into thinking that MSIT has it easy because they only have to deal with a single, homogeneous platform and one vendor. Microsoft has some gravitas in the software business—to be sure—but it is also part of a much larger ecosystem of ISVs, partners, hardware, software and services vendors, contractors, financial institutions, manufacturing, hosting and network companies, packaging, shipping and distribution companies, VARS, and more. Like many large enterprises, Microsoft depends upon these business partners throughout the ecosystem for its continued success. And guess what? As a group, they probably use every platform, system, wire protocol and data format on the planet. On a daily basis that means the big dogs at MSIT face very serious, enterprise-class challenges around interoperability, identity management, authorization, scalability, availability, content management, and telephony integration. Sound familiar? All of this and more exists in a highly heterogeneous, globally distributed ecosystem. If MSIT can devise a solution or architecture that works well on our platform in this environment, there’s a pretty good chance it will work well in your enterprise, too. Are you beginning to see where I’m going with this?

Hopefully, you’re beginning to come to the same conclusion I have. When MSIT architects have something to say, it is usually worth listening to. I’ve learned a lot from Aaron Hanks. Like: Be consistent, be persistent, speak softly and carry a big set of requirements. Nick Malik and Gabriel Morgan have great blogs that range over a wide array of enterprise architectural issues. Even if you don’t always agree, you usually find them interesting and thought provoking. I think you’ll also find that they generally understand the magnitude of the challenges in distributed computing in the enterprise today. Think you’re ready to run with the big dogs? Try the MSIT pack out for size.

Got SOC?

CurtD — Wed, 23 May 2007 03:37:00 GMT

Good grief! Not another pesky TLA? Well, not really. SOC stands for service-oriented culture—an awkward term I use to describe a phenomenon that is an essential element of developing an SOA and sometimes conspicuously absent in the enterprise. Once I’d used this term a few times in my talks, my fellow evangelist and erstwhile cohort in crime, Allan suggested I write a blog and take ownership of it.

A lot has been written to define what an SOA is, what its benefits are, and how to develop one. So much has been written in fact that the term ‘SOA’ may begin to suffer from what Jacques Derrida called effacement—the dissolution of meaning from overuse. Yet, as a wandering evangelist, I frequently find that SOA doesn’t have the momentum in the enterprise that one might expect given the honors that have been heaped upon it. I’ve started to think that the enterprise yearns for the virtues of SOA the way that Augustine of Hippo yearned for the virtue of chastity: “Grant me chastity and continence, only not yet.” I understand Augustine’s hesitation, but what about the enterprise? Why does the enterprise seem hesitant about the virtues of SOA?

Many organizations have overcome the inertia of the status quo and moved toward SOA with enthusiasm, of course—but many others are still moving forward at a snail’s pace—if at all. Even the enthusiasts won’t necessarily meet with immediate success on this front. And btw, having a bunch of services lying around your enterprise doesn’t constitute success with SOA, either. If you want to read a good article that keeps SOA in sharp focus, take a look at Control and Visibility in a Service-Oriented Architecture by my DPE colleague, Keith Pijanowski.

One factor that creates a drag on SOA adoption in the enterprise is a need for a well-organized and robust service-oriented infrastructure (SOI). Other factors at work hereare the trials and tribulations of attaining standardized, cross-platform service implementations. These can both be important obstacles to SOA adoption at times, but these factors have received a lot attention already; they’ll probably receive more in the future.

One big reason for the sluggishness toward SOA that has been much neglected is the lack of service–oriented culture. SOA involves a true paradigm shift (Yes, I know this is a much hackneyed term—especially in information technology—but it’s very a propos here.) Part of every paradigm shift is a gradual process of cultural evolution. Paradigm shifts in computing are somewhat different from the scientific kind that Thomas Kuhn first described because they leave more room for doubt. When a new paradigm occurs in the scientific world, the shift has tremendous momentum because it provides superior explanatory and predictive power. Going from Newtonian to Einsteinian physics is a good example. Like a glacier, movement is slow but inevitable.

In the computing world, old paradigms often seem to have a strong inertia of their own, overlapping more broadly with the new paradigm. When N-tiered architecture appeared on the scene, for instance, client/server architecture and development continued largely undaunted for quite some time. There are many reasons for this lagging effect, such as the lack of new tools, the need to fully leverage investment in the existing technology, the ramp-up time needed by developers to acquire new skills, and skepticism about the need for a new paradigm or its potential to fulfill its promise. But I think ‘cultural inertia’ is also fundamental to this phenomenon. Paradigm shifts push people and teams outside their psychological comfort zones—and this takes time.

Moreover, I think that this cultural inertia is greatly underestimated. The larger the community is, the greater the inertia can be—especially in risk averse organizations. Looked at from this perspective, the cultural factor helps demystify the sometimes torpid embrace of SOA in the enterprise.

In simplest terms, an SOC is the community mindset that has bought into the SOA paradigm. I’m not talking about the developer community alone. On the contrary, SOC must become pervasive in the IT community as well as business stakeholders in order to achieve the optimal benefits. Nor am I just talking about raising awareness about SOA, because success with this paradigm often requires far more. Ultimately, the development of an SOC may require an organization to transform itself in important ways. Architects and developers will need a new mindset and the skills to match it. The same is equally true for testing, deployment, infrastructure and operations. Each of these is a key facet of the community that must embrace service-orientated principles and fundamental change. Funding SOA can require fundamental changes to the budgetary process or new chargeback scheme’s to pay for services shared across multiple, semi-autonomous business units.

On the server side, an SOC may mean developing highly reusable services, but it also means designing facades that will position the business to take advantage of off-premise services as they become available. On the client side, an SOC can mean encouraging developers to fully leverage existing services in their designs and help drive new service requirements they are discovered. On the business side, SOC can mean coordinating joint development efforts between separate business units, being alert to opportunities to reduce cost or time-to-business value by consuming services in the cloud, or even providing services that can be securely accessed by partners or customers, improving business agility or opening new markets. In some cases, SOC will mean that parties from many different roles and areas of responsibility must work together to ensure that real interoperability across platforms is achieved with service and data contracts that actually model meaningful and useful business abstractions. Examples are abundant, but the point is that SOA must be ingrained in the culture throughout the enterprise.

Perhaps you will think I’ve gone too far by suggesting that business stakeholders are part of the SOC. Au contraire, mes amis! Putting aside the obvious fact that transforming IT will require real business sponsorship and investment (i.e. money) to succeed, I think SOA is most powerful when it reflects service-orientation in the business architecture itself. In fact, one could argue that many of the tenets of SOA were fundamental to business architecture long before they were introduced as the operative paradigm in IT. If you’re not convinced of this, I suggest you read Pat Helland’s superb article Metropolis –he’s not only more convincing, he’s more entertaining too. [Btw—it’s nice to see a card carrying member of the Barbarian Horde come back to Microsoft—for those who’ve been around long enough to get the reference.]

Surely, the tenets of contract- and policy-based design, service autonomy, and explicit boundaries are important fundamentals of business architecture as well as solution architecture. I would argue that SOA is most effective when business and IT are of like minds—that’s what an SOC is all about. It’s a shared commitment to a set of organizing principles. Business and IT can derive similar benefits from SOA—agility, standardization, adaptability to change, and quality of service, to name only a few. I really like Mohammad’s blog on this topic: Selling SOA to business stakeholders.

Want to accelerate the SOA paradigm shift in your enterprise? You may need to expend some energy nurturing the SOC as part of the process. I don’t think I can provide a simple recipe for this type of transformation, but to me, it’s less about ‘architectural governance’ and more about socializing the concepts, raising awareness, building consensus and encouraging buy-in about SOA. It’s cultivating the SOA mindset throughout the enterprise. Developing SOC is the indispensible human dimension of making the SOA paradigm shift. Without it, your success with SOA may be limited and slow in coming. Need a little help? Call your friendly neighborhood architect evangelist.