Michael Yeager's MSDN Blog : Software Architecture

Talking about EUCCs

mty — Wed, 23 Sep 2009 22:59:00 GMT

I have been getting emails from lots of you wanting the goods -- the real life examples of End User Composed Composites (EUCCs), and more information on the how and why of designing them...

Unfortunately I haven't been blogging about EUCCs for a while - instead I have been doing presentations. Those of you who are Microsoft FTEs can view the "Designing Capabilities Not Applications" session in the TechReady9 On Demand archives. The "Designing Capabilities Not Applications" session is in the Architecture Track: ARC304. Description as follows:

Many MOSS, OBA and other Composite applications are moving the application design decisions away from the Architects and Developers and putting them into the hands of the end users. This is a paradigm shift that changes the game and radically shrinks the development cycle. To be successful at end user driven designs, Architects and Developers need to think in terms of designing and delivering Capabilities rather than purpose built applications. End users then use workflow and rules to structure their own high value business solutions out of these Capabilities. This presentation will use MOSS and OBA examples from the field to explore the emerging patterns and practices that Architects and Developers can use to factor requirements into capabilities rather than purpose built applications.

For those of you who are not Microsoft FTEs, I am doing a presentation at the SharePoint 2009 conference in Las Vegas Oct. 19 - 22, the web site is: http://www.mssharepointconference.com . The session is SPC268 "Designing Capabilities Not Applications, with SharePoint 2010 Composites". The full description of that presentation is:

Learn about the power of end user composed solutions and how to plan, design and think in terms of capabilities to design them. We will discuss a conceptual pattern for differentiating and evaluating different SharePoint/Office System solutions and for understanding the advantages of Capability-driven solutions along with the institutional road blocks to these solutions.

A recorded version of that session will also be available to all conference attendees a few weeks after the SharePoint 2009 Conference.

What the heck am I talking about?

mty — Sun, 26 Apr 2009 16:27:00 GMT

Hey, I'm talking about EUCCAs and Versatilities.

My last couple of blog posts are my personal crusade to get SharePoint architects and developers to focus on the most productive way (in my opinion) to use SharePoint as an application platform.

A EUCCA is a specific type of Composite Application - an End User Composable Composite Application.

A EUCCA is a Composite Application that specifically hands over the design of the Presentation and Productivity layers to the end users. Any composite application where the developers end up controlling the Presentation and Productivity layers is not a EUCCA.

Versatilities are the parts of a EUCCA that the end users compose. So each EUCCA contains a set of Versatilities.

A Versatility, regardless of it's functional requirements, must satisfy three critical non-functional requirements:

Movability
Assemblability
Composability

Any component, reusable or not, if it is not Movable, Assemblable and Composable, then it is not a Versatility.

That's what I'm talking about.

Talleyho :)

Requirements and Versatilities

mty — Sat, 25 Apr 2009 01:21:00 GMT

Reusable components. A lot of work and effort and thought has been put into reusable components...

OK, so let's talk about a specific type of reusable components... let's talk furniture design and Versatilities.

There is a certain Scandinavian furniture company, not sure if I am allowed to say their name, but they are incredibly successful at selling really nice, practical, well designed inexpensive stuff.. But their designs are significantly different from traditional furniture designs because their business model requires them to meet some very stringent non-functional requirements.

First off, a piece of their furniture has to fit in a box that weighs as little as possible, and be transportable home by the customer themselves. So Movability is a huge non-functional requirement. Second their designs have to be easily assembled with only simple graphic instructions, and a few included tools. So Assemblability is another very important non-functional requirement. Third, their designs are designed to look and work great together across completely different types of furniture and housewares and accoutrements. All of their stuff has to be nicely composable into different attractive interior designs and styles. So Composability is also a hugely important non-functional requirement.

Movability
Assemblability
Composability

These are the uber-requirements. These are requirements that have to be satisfied no matter what the end user's requirements. If what the end user's want can't be designed to be Movable, Assemblable, and Composable - forget it. This company isn't going to deliver it. The end user (customer) will have to go elsewhere.

SharePoint Versatilities are versatile components that have these same three non-functional uber-requirements: Movability, Assemblability, and Composability. Therefore you have to design from the get-go for Movability, Assemblability and Composability - otherwise you're not designing Versatilities.

OK, so you have a bunch of business users, and they want an application that does x, y and z. So what are you going to do? If you design them an application that does x, y and z, and exactly x, y and z, then you have a purpose built application. If you get the requirements for a reclining chair, and you then build a one-off reclining chair right in their own living room, as one solid monolithic reclining chair - then what you have is perhaps a great reclining chair, but it only works now, for that particular user with their current decor. If they want to "recompose" their living room into a different design, then they'll have to bring the furniture craftsmen back in and rebuild. Sound familiar?

If you want Versatility - if you want applications that the end user's can move around, assemble and reassemble, and compose and recompose, then you have to take their requirements, and do a whole different level of analysis on them. You have to look beyond the x, y and z, and treat x, y and z as a sub-set of a larger set of possibilities - and you have to explore how Versatilities can be designed to deliver that mix. In other words, like our Scandinavian design heros, you have to be really smart about the design.

So now let's say you've been super smart - and you've come up with a slick set of Versatilities that can do x, y and z and so much more - well now you have a more difficult problem. Now you have to convince your stakeholders that your set of Versatilities is a superior solution to their x, y and z requirements. SharePoint users in general have totally realized the value of Versatilities. They love lists and columns and views and content types and web parts, and everyday they realize tremendous value out of moving them around, reassembling and recomposing them into new solutions. But first off, most SharePoint users didn't arrive at their SharePoint site with a clear set of requirements. They arrived at their SharePoint site thinking - here's a whole set of tools, what can I do with them? And second off, what if your stakeholders aren't SharePoint users at all? Quite often you're dealing with CXOs that only have a vague conceptual understanding of what is going on in SharePoint - and they're used to the waterfall lifecycle - they expect you to gather requirements, and then deliver an application that exactly satisfies those requirements.

How do you convince your fickle and persnickity bunch of stakeholders that they should care about Movability and Assemblability and Composability - how do you convince them that their interests are best served by your set of brilliant Versatilities?

Convincing stakeholders to care about non-functional requirements is always hard. You have to plan, you have to prepare, you have to lay the ground, you have to do great drawings and presentations, you have to work at hitting the right notes from the very first conversation. You have to get them to understand that Versatilities will give them the agility and speed to continuously execute on their business objectives.

But you can't sugar coat the downside because it will bite you back. Applications composed using a set of Versatilities always require a little more work on the end-user's part - they require more clicks than a purpose built application. Just like the Scandinavian furniture, they have to be assembled, and they come with directions that the end-user's have to follow... So yes, their users will have to do more work and learn a few things, but in return they will be able to compose the application in their own SharePoint site in a matter of hours - and then be able to change it themselves whenever it requires changing.

Of course you have to show examples. Most stakeholders don't know what they want until they see it. So show them as many similar end user composed SharePoint applications as you can - and if you have a running version, show the stakeholders how the end user's themselves can change and evolve the application as their business changes and evolves - without the need to call in the developers for another 6 months of rebuilding in order to add an account code, or to deliver the same application to a new office in Timbuktu.

I'll walk through some real examples next time...

eXtreme End-User Driven Architectures (XEUDAs)

mty — Fri, 07 Nov 2008 18:03:00 GMT

There is an emergent solution architecture which the most ingenious of our end users are piecing together without our help. It is an architecture without a name - so let's give it one:

the eXtreme End-User Driven Architecture or XEUDA (zoo-da)

A XEUDA is an Architecture - not an Application. It is an architecture of many applications that end-users compose to empower complex business processes. End users do this by themselves - no developer/IT intervention required.

XEUDA is an architecture that can be changed, rearranged, reconfigured, repurposed, redesigned, re-architected by the end users. Right now end users can only do this to a very limited degree, only with a small sub-set of applications, and only to drive particular activities of some business processes, but if the application architect and developer community, along with the IT governance powers that be, were to relax their grip and embrace this impulse, XEUDAs will push IT controlled architectures aside by producing productivity gains of 10X or more.

Anywhere there is an Enterprise MOSS infrastructure with even a handful of power users you will sense the yearning for XEUDA. MOSS power users and champions build fabulously flexible applications on their MOSS sites. MOSS is a wonderful end-user driven system. But it is not extreme enough - inevitably users drive up to the edge where pieces can no longer connect, where their InfoPath or Word or Excel docs, their content types and custom lists, and their SharePoint enabled LOB applications, are left hanging on a library ledge - their structured and unstructured data in danger of being backed-up into oblivion.

And when the developers and architects are brought in, and the problem is laid out and the requirements gathered, their next impulse, more often than not, is to move to a purpose built application - ripping control out of the hands of the users, and placing it in the hands of a Solution Lifecycle and project managers and development teams and a change management process which may take months or even years to hard boil what the end-users had loosely assembled in a matter of days...

We have all the tools and skills to give those magnificent MOSS and OBA applications the ability to turn into more powerful and more flexible XEUDAs -- what we don't see enough of are architects and developers that are advocating and building the end-user architectable elements that a XEUDA requires; and agile, apolitical, IT governance teams that are ready and willing to hand-off the architectural keys to their power users and domain experts...

N-Fractal Architecture

mty — Thu, 12 Jan 2006 20:40:00 GMT

I have to confess that since the very beginning of my software development career, I have chaffed under the yoke of N-Tier Architecture. It’s not the architecture itself that causes those big sore spots on my neck and shoulders; the problem is the way it is typically projected into the development arena. Let me explain.*

In its simplest form, N-Tier Architecture looks like a two-story building with a basement. The building can have as many stories as you like, but truth be told, the N in N-Tier is pretty much always equal to 3, 4 or 5. In this case: 2 stories + 1 basement = 3 tiers.

In the basement of our two-story building you have all the utilities that provide water, electricity and heat (the data layer). On the first floor you have a store that provides your commodities: your bread, eggs, milk, butter and juice (the business logic layer). And on the top floor is the apartment where life really goes on - where the eggs get cracked, the bread toasted and the juice poured (the user interface layer).

And that’s perfectly logical, and it works great, and software is all the better for having this underlying structure. But the problem comes when you are the one working on the UI layer trying to install the refrigerator or… the toaster.

In many projects, the way N-Tier is projected onto the build process, a toaster is not a whole toaster. It’s just the UI of the toaster. So you have that sliding lever for lowering the bread into the toaster, and a sliding switch for setting the brown level of your toast, and that’s it. If you want the rest of the toaster -- the grid that actually toasts the toast and the spring that pops the toast out at the end -- for those you have to go talk to the Business Logic woman.

So you go down to the first floor and you lay out your crazy and wild idea for a toaster to the Business Logic woman. And maybe she buys into it. Maybe she thinks toast is a good thing, and she agrees to build you your nichrome wire/mica thingy that toasts the toast. But then she explains that it’s going to have to live on the first floor. And why is that? First of all, all Business Logic lives on the Business Logic layer, not on the UI layer. And second, you can only plug into the power in the basement from the Business Logic layer, not from the UI layer. So the toaster can’t be in the apartment, it has to be on the first floor.

Ok… Alright. Well, that’s not what I had in mind. I just want a toaster. But I’m sure I can figure out some way to get the toast back up to the apartment - maybe a hole in the floor with some really big springs!

What I’m trying to get at here, is that N-Tier may look like a building, but quite often we don’t make it work like a building.

The reality that N-Tier ignores is that a toaster is an N-Tier Appliance in its own right. N-Tier Appliance? And there are a whole lot of N-Tier Appliances on all of the floors of the building. The furnace in the basement is an N-Tier Appliance: with it’s own UI, it’s own business logic, and it’s own data layer; as is the cash register in the store on the first floor; as is the toaster and the refrigerator in the second floor apartment.

And if you look inside each of the tiers of the N-Tier Appliances that are inside each tier of your building, you’ll find a whole new set of N-Tier Appliances. And inside the tiers of those Appliances, you’ll find other N-Tier Appliances**. And that’s how our simple picture of an N-Tier building summersaults right before our eyes into a fractal; and why, if we take software development to that next level beyond N-Tier, we arrive at this notion of N-Fractal Architecture.

It’s really not all that exotic. We do it already with buildings and toasters without even thinking about it.

So how does one go about implementing an N-Fractal software architecture? I'm working on it.

michael

* Some of you may be wondering why I’m talking about N-Tier architecture rather than SOA. Isn’t N-Tier so yesterday? I don’t think so. SOA is a bunch of N-Tier applications that talk to each other. N-Tier hasn’t gone away, it’s just been super-setted.

** Within the N-Fractal paradigm these are modeled as "N-Fractal Appliances".

Software as Systemic Core

mty — Thu, 05 Jan 2006 03:14:00 GMT

Developers/architects of software applications generally think of those applications as tools. Tools to be used by individuals, teams, and corporations in the achievement of their individual, team and corporate goals.

Office is the classic example of a "transparent" software tool that any individual or enterprise can use singlely or multiply without the tool itself directly imposing any particular organizational structure or style on those employing it.

Even systemic tools such as ERP and CRM systems are planned and painstakingly imposed upon whole divisions rather than being the driving force for those divisions. Portal systems are agonizingly architected to mimic the organization of the corporation rather than to organize the corporation. Business Intelligence systems are built and rebuilt and then rebuilt again to aid decision making by the corporation rather than to decisively guide the corporation.

We haven't yet fully come to terms with the concept of software as the systemic core of an organization or corporation... but we will.

Just thinking.

michael