I just came across this whitepaper which discusses how CardSpace (formerly InfoCard), together with the Identity Metasystem - Microsoft's vision for an interoperable architecture that allows Internet users to use context-specific identities in their various online interactions - address Internet user privacy.

The paper is worth a read if you're interested in understanding how CardSpace works (it's on its way with Vista after all), both from an architectural and user perspective. Even if you're not particularly interested in the technology, it provides a good summary of the threats to and challenges of privacy assurance as well as EU data privacy law (which as you will find is not just an issue for organisations established in the EU).

Posted by nmacehiter in Identity Management | Permalink | Comments (0) | TrackBacks (0)

In a recent post Nicholas Carr calls out a recent Harvard Business Review article (currently freely accessible) by Andrew McAfee, whose work I highlighted in August. In the article, McAfee sets out to help managers grapple with the challenges of technology adoption in the face of an abundance of technologies, a chequered history of IT project success, a more general questioning (thanks to Carr) as to whether IT really matters and whether organisations should actually be doing IT themselves. I certainly found myself agreeing with a lot of the context setting from McAfee.

McAfee goes on to explain that:

technology projects are increasingly becoming managerial challenges rather than technical ones. What’s more, a well-run IT department isn’t enough; line managers have important responsibilities in implementing these projects

Again, difficult to refute. IT and business are so intimately intertwined these days and the focus of IT investment is shifting away from the automation of non-differentiating business processes in the back office and towards those processes which do differentiate: the ones which are often ad-hoc, dynamic and collaborative in nature. Unless the business is involved in identifying the right technology and then facilitating its adoption, the chances of success are limited. Whilst the business knows this, the problem is

they’re not clear where, when, and how they should get involved

Why? According to McAfee it's because managers lack a model for the role of IT, its organisational implications and what they should do to help it succeed. Our research here at MWD is certainly consistent with this. So, where does this model come from?

That's where GPTs - General Purpose Technologies - and organisational complements come into play. GPTs are

innovations so important that they cause jumps in an economy’s normal march of progress

with IT following on from earlier examples such as electric power, the transistor, and the laser. Organisational complements are changes in the ways that organisations do things which multiply the effects of GPTs. In the case of IT, these complements are better-skilled workers, improved teamwork, redesigned processes and new decision rights. McAfee believes that IT is different from other GPTs in terms of the relationships to these different complements. He believes there are three categories of IT which vary in terms of the importance of the different organisational complements:

- Function IT - assists with the execution of discrete tasks and doesn't bring complements with it e.g. spreadsheets, CAD
- Network IT - facilitates communication and collaboration between individuals and lets complements emerge e.g. email, blogs, wikis
- Enterprise IT - specifies and implements business processes and imposes complements e.g. ERP, CRM, SCM

One could certainly argue with the classification since different technologies may fall into different categories dependent on the business process but overall it makes a lot of sense to me - it's recognised, for example, that big enterprise applications often require changes to business processes and governance approaches.

This classification forms the basis of the missing model, since it provides managers with a way of thinking about the capabilities they need - task execution, communication etc - during technology selection; the complements they need to put in place to facilitate adoption; and the optimisation of complements they need to perform to maximise the return from technology. The article provides some useful case study-based examples of the model in use.

I think McAfee has done a great job of simplying things or, as Carr puts it:

in adding precision to the language we use to discuss complex subjects. It helps us get beyond big, ill-defined generalizations.

I, like Carr, think the classification of IT is too simplistic (but then it is a model!):

It can prevent us from seeing how categories blend together. By drawing bright lines between things, it can give the illusion that those things are more distinct than they really are. I sense that problem here (even while granting the usefulness of McAfee's categorization). Take the identification of CRM as an enterprise information technology. Isn't that assumption exactly what doomed so many big CRM projects? The projects lost sight of the fact that CRM is as much a functional tool, a tool that helps individual employees, like salespeople, do their work better, as an enterprise system. CRM, in other words, is as much FIT as EIT. And, in fact, there's a lot of NIT in it as well.

However, I disagree with Carr's conclusion:

McAfee's article may not be quite as clarifying as it is intended to be.

Had McAfee had stopped at the classification then I would have agreed. It's the marrying of the technology classification to the organisational implications where McAfee clarifies things, since it helps to facilitate a dialogue between business and IT in a language which both sides understand. Equally importantly, it moves beyond the technology selection phase to outline the role of the business during adoption and subsequent exploitation.

Posted by nmacehiter in IT Governance | Permalink | Comments (0) | TrackBacks (0)

...part of the title of two recent posts (here and here) from one of my absolute favourite bloggers on SOA, Steve Jones (CTO of Application Development Transformation, Capgemini). Anyone trying to understand what SOA is really about, in real-world practice, should read these.

The very short executive summary (of these and his general theme): SOA is about your entire organisation's attitude to how it thinks about itself and about its relationship to technology - it's not about ESBs, BPEL, or any of the rest of that alphabet soup.

This guy hits the spot with almost every post and he's not afraid to tell it like it is, warts and all.

Some Friday reading for you!

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

Last week I had the opportunity to join a podcast debate with Ronan Bradley, Joe McKendrick and David Linthicum, looking at the question of reuse within SOA initiatives - why is it difficult, and should it be the thing we're aiming for, anyway? Perhaps it was disappointing that there wasn't much disagreement: nevertheless I think we hit on a lot of good points.

From my perspective the things that came out were:
- don't fall into the trap of creating services "because you can" - that way you're almost certain to fail in even promoting service use, let alone reuse
- focus on the "A" of SOA - "it's the architecture, stupid"
- look at reuse as one part of the overall value of SOA - along with more flexible infrastructure and applications; lower risk software projects; more business-comprehensible systems; and so on
- when looking at vendor case studies and marketing messages around reuse, take all claims with a big pinch of salt.

Posted by ebizQ in Architecture | Permalink | Comments (0) | TrackBacks (1)

I've just had my first cross-atlantic Podcasting experience, with Dana Gardner and Steve Garone in Dana's BriefingsDirect SOA Insights Edition. That was a lot of fun - we covered virtualisation and ERP, Oracle and EMC's stealthy plans, and plenty of things to do with SOA of course! Do tune in - or download the transcript.

P.S. for more SOA goodness, I also wrote the following article - Services, not software - for IT-analysis.com. Feel free to check it out.

Posted by joncollins in Architecture | Permalink | Comments (0) | TrackBacks (0)

I recently participated in the first edition of a weekly podcast, featuring independent IT analysts (and the occassional guest) discussing recent events in the world of SOA. If you want to hear my thoughts on BEA's SOA 360, IBM's recent raft of announcements and Borland's role in the SOA lifecycle then the podcast is here. Alternatively, there's a transcript of the discussion here.

Posted by nmacehiter in Architecture | Permalink | Comments (0) | TrackBacks (0)

Last week, the Liberty Alliance announced the final version of its Identity Web Services Framework (ID-WSF) - I briefly touched on ID-WSF back in April when discussing Liberty's approach to user-centric identity. I have to admit, I have always struggled to get my head around ID-WSF, which Liberty defines as providing:

the framework for building interoperable identity services, permission based attribute sharing, identity service description and discovery and the associated security profiles

Liberty has used a variety of resources, from marketing requirements documents to webinars, to help others facing a similar predicament. I put these resources to good use and finally got to the bottom of identity services, permission based attribute sharing and what these might mean in business terms. For all the details, take a look here.

Posted by nmacehiter in Identity Management | Permalink | Comments (0) | TrackBacks (0)

So Microsoft is finally out of the closet. After years of shrugging off any enquiries about SOA and preferring instead to talk exclusively about something called "service orientation", the company has put its name to a SOA conference which ran last week in Redmond. It's really a BizTalk and Office conference, actually, but SOA (and BPM) are big themes.

It's a big moment for SOA. Microsoft traditionally eschews the big software platform buzz-phrases - it never talked about having an application server, for example, or an Application Platform Suite - preferring to leave the mouth-frothing and feveish-attention-grabbing to the Java crowd - but it seems that SOA's momentum has finally made it explicitly hitch itself to the SOA wagon.

Not without a bit of a side-swipe at the current SOA tooling players, though. The news release that accompanied the staging of the conference made reference to Microsoft's "real world" approach to SOA - in contrast to other vendors' approaches which "major on the need for large scale enterprise infrastructures". I'm sure this has nothing at all to do with the fact that Microsoft's real strengths lie in its relationships with developers, in contrast with the "enterprise infrastructure" strengths of competitors like BEA, IBM, TIBCO et al...

John deVadoss, Microsoft's director of architecture strategy, talked about an "industry dialogue around large-scale SOA implementations not delivering the promised return" and positioned Microsoft's strategy as being much more about helping customers take incremental steps towards SOA.

I think this is a case of Microsoft attempting to invent an industry narrative that doesn't exist, in an attempt to convince its "public" that a developer-focused approach is the best way to go. But none of the companies I've talked to are dumb enough to try and re-engineer their entire organisations' IT infrastructures top-down in some kind of elephantine SOA engineering folly. Hell, *any* big-bang infrastructure reengineering project generally falls on its backside: unless you're in a privileged position and are able to build a new company from the ground up you have to take a stepwise approach, justifying the business value of incremental investments as you go. That's the same for SOA as anything else. But the truth is, you need an approach that puts the right tools into the hands of developers as well as the right infrastructure (among many other things) - SOA success can't be reduced to a question of "developers first" or "infrastructure first".

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

I have discussed the Eclipse Higgins project on numerous occassions over at the MWD blog (here, here and here for example). I recently had the chance to discuss Higgins with Tony Nadalin, Chief Security Architect for IBM's software group and one of the participants in the project.

The key component of Higgins is the Identity Attribute Service (IdAS), an abstraction layer that is designed to allow developers to access identity data in a variety of repositories (LDAP, RDBMS etc) without having to concern themselves with the underlying data access API. Since first encountering Higgins, I have often wondered why the IdAS is any different from virtual directory solutions - apart from the obvious support within Eclipse - so I asked Tony. The answer is the IdAS Data Model which aims to

provide a common representation for identity, profile and relationship data in order to provide interoperability.

In other words, IdAS not only attempts to mask the the complexity of dealing with a wide variety of repositories but also to grapple with differences in semantics and so provide developers with a common way of thinking about and accessing identity data. The development of a common data model is a significant undertaking and I can imagine the lengthy and no doubt heated debates amongst the likes of IBM and Novell in coming up with it.

Higgins will eventually make its way into "enterprise identity management" solutions from the likes of IBM and Novell (something confirmed to me by both Tony and Dale Olds, one of his counterparts at Novell) so it is definitely worth watching. IdAS and the associated data model should certainly make life easier for the vendors grappling with the proliferation of identity data stores and formats within their own product. It should also help the customers of those products, many of whom are gappling with the fragmentation of identity data I discuss in our identity management report.

Posted by nmacehiter in Identity Management | Permalink | Comments (0) | TrackBacks (0)

Back in April I called out Cyber-Ark's privileged account management solution and its role in compliance. At the time I highlighted Cyber-Ark's partnership with IBM:

This is not something that is acknowledged, at least in my research, by current identity management players, and it's therefore no surprise that Cyber-Ark has established partnerships with the likes of IBM with Tivoli Identity Manager.

This partnership reflects the fact that privileged account management is really a specialised case of more general account management and so integration with provisioning solutions is an obvious step for Cyber-Ark. The company took a further step, announcing a partnership with specialist provisioning vendor Courion, which will see Courion offering Cyber-Ark's Enterprise Password Vault as an optional add-on to its provisioning solution. This should certainly help to extend the reach of Cyber-Ark and provide Courion with some differentiating capabilities. However, Cyber-Ark needs to make similar inroads with the likes of BMC, CA, HP and Oracle if it is to get on the enterprise identity management radar.

Posted by nmacehiter in Identity Management | Permalink | Comments (0) | TrackBacks (0)

Jeff over at Service Oriented Enterprise is grumpy about the approval of the SOA-RM specification by OASIS.

He says it's only really useful for a very specialised audience - the implication, I think, is that the ideas are so abstract that they're not of any practical use to real practitioners.

Now I'll admit that the spec is not the most accessible read in the world - it's kind of dry and abstract - but then it's a specification of sorts! And it's a heck of a lot more readable than many I've come across. Moreover I personally feel that it offers some really interesting ideas that have a lot of value to anyone still grappling with SOA; or to anyone who suspects that the majority (and over-simplified, instant-gratification) view of SOA that focuses on application development is bogus.

Specifically the document makes the following sensible observations/assertions (in no particular order):
- SOA is particularly suited to situations where multiple domains of control are at work and the solution needs to cross those domains
- you don't need to be using Web Services to pursue SOA
- services are distinct from capabilities and you need to understand this difference
- SOA thinking has to move beyond a focus on services, to a focus on facilitating interactions between services
- contracts and policies govern the conditions under which service interactions take place; but they play distinct roles and the differences are important.

If I've got one grouch of my own it's that the document doesn't, for me, call out explicitly enough the fact that what it means to deliver a service is the outcome of operational considerations, as much as it is about design and development. In short, a service is something you experience, not something you build. To really "get" SOA, you have to think about all the phases of IT value delivery - from design and development, through deployment and operation to change management and back around again.

Posted by neilwarddutton in Architecture | Permalink | Comments (0) | TrackBacks (0)

Who wouldn't want to be agile? The word itself suggests being lean, lithe, quick-footed, having all the moves and the instinct to use them. 'Agile' is hip, it's sexy, and unsurprisingly, ever since the term has been applied to software, it's had plenty of positive press both in the media and in the IT department.

Software methodology has always gone in waves, flip-flopping over time between structure and flexibility. So waterfalls gave way to spiral development models, and V-lifecycles faced off the new freedoms of Rapid Application Development, itself re-iterated as the more constrained Dynamic Systems Development Method. This cycle continues, with programmer’s programmer Kent Beck cutting the Gordian knot of convoluted software processes, slaying the dragon of overbearing management and picking up a lucrative publishing contract on his way down the mountain. Others have jumped on the 'agile and adaptive' bandwagon – indeed, some claim to have built it, how else would Mt Beck have got up the mountain?

It was ever, and it probably will ever be, thus. A good illustration of such thus-ness is the current debate around exactly what is agile development. More than once recently, I’ve heard the remark, “That’s not real agile.” For perfectly valid commercial reasons, of course, it is important to be seen as agile; equally, this can be upsetting to those who see their own, principled approaches being sullied by unscrupulous marketers. Indeed, the DSDM consortium is insisting that it is agile too (or indeed, “an enterprise-ready wrapper for agile practices”; “Nah, that’s not agile, its more adaptive,” others will say. How the winter evenings will fly by.)

Don’t get me wrong, I’m all for agile – whatever it is. But that’s an important ‘whatever’. It s quite easy for an organisation to say, “we’re agile,” However the reality could mean, “we’ve adopted the agile manifesto and its principles to the letter, and everyone in our dynamically organising teams can quote them from memory”; or equally, “we’re chaotic and we don’t want a formal development process so we’ve chucked a few trendy terms in the pot and we’re using them to fool our not-that bright IT management.” Even if the latter is not the case, how can businesses that had their fingers burned with RAD be sure that agility is delivering the goods?

Simply that, in fact – whether it’s delivering the goods. But what criteria to use for delivery? It is one thing to update a release of software, but quite another to make a positive difference to users. For commercial businesses and public organisations, the single criterion that makes any sense is, “does the delivery help the organisation in business value terms?” This can be couched in a whole variety of ways – user productivity for example, staff well-being and customer satisfaction – but again, all of these should be supporting the overall financial health of the organisation – either making or saving money – or they are missing the point: this is as true for public as private organisaitons.

The second factor involved in delivery however, involves the longer-term, sustainable benefits of any deployment. It is one thing for example to deliver the most basic of Web sites in ten days, which enables a company to start selling its products or reporting to its clients. As the company gets successful however, is the Web site going to keep up? Are the costs of any workarounds going to grow, such that in time, they outweigh the benefits? Will the increasingly demanding client base stop seeing the site as a useful tool, but more as a bottleneck? Everybody has their story of how the prototype became the production version – not the kind of early delivery that anyone would advocate, given the choice. If an organisation is going to deliver functionality early, not only does it need to add value at the start; also, later deliveries should work to shore up any kludges at the same time as adding to the functionality that’s already been deployed.

Agility doesn’t only exist within a project; it should also be present without. Perhaps the greatest test of agility of all, is the ability of a project to recognise when it is no longer able to add value, and has therefore reached the end of its useful life. Agile indeed, will be the developer who recognises his or her skills are no longer necessary on a project, and who is prepared to reskill or make themselves redundant as a result. It’ll take more than a methodology to tell them that.

Posted by joncollins in Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)

Hello! Welcome to this new team blog by the three core MWD analysts: Neil Macehiter, Neil Ward-Dutton, and Jon Collins. We're hoping to live up to the title of the blog: regularly posting our thoughts on software infrastructure topics - principally around software development, integration, architecture, BPM, security, identity, and management - and hopefully providing a fresh perspective on trends, vendor announcements and discoveries we make as we work with clients. In addition we hope to be able to point you to items of interest that we find as we plough through the blogosphere's egosystem.

Our perspective at MWD is firmly rooted in the notion of aligning IT and business. Every IT investment and initiative should deliver business value, and should bring IT and business closer together. We look at software infrastructure trends, technologies and problems in this light - not looking at technology for technology's sake, but always asking how an initiative, announcement or project delivers business value. Hopefully some of this perspective will come through as you read our blog.

Posted by nmacehiter in | Permalink | Comments (0) | TrackBacks (0)