You get what you give

Brian Sommer asks Why are we paying bonuses? He's reporting on the frustration among executives over bonuses as entitlements, mercenary employees, how to motivate employees, and diminishing consulting skills in the workforce. Which is a lot of ground to cover in a single post.

What stuck with me most was Brian's description of local Chicago execs complaining about their employees increasingly having a "what's in it for me" attitude.

Ok. Forgive me for not feeling the executives' pain here, but what exactly do these execs expect to happen when their businesses reward loyalty and job tenure with... what?

Let's list the disincentives mainstream contemporary US businesses have come up with:

• No job security / layoffs
• Long hours
• More work than life in the work/life balance (e.g. Blackberries and laptops on vacations)
• No pensions

If a company's hiring policies lead it to mostly hire rational people, then the rational and expected response to these disincentives is a mercenary attitude. To paraphrase John Maynard Keynes, when the incentives change, I change my behavior. What do you do?

This is what the "ownership society" looks like - and it looks an awful lot like every man for himself. I've got mine... and good luck to you.

Today's NY Times has an article that touches on this topic and, frankly, made me sad when I read it. What Do I Do? Depends on What Week It Is describes Sean Aiken's quest to work a different job every week for a year and is chronicled on oneweekjob.com.

But here's the part that broke my heart (emphasis mine):

The 20-somethings who turn to One Week Job find in Mr. Aiken “an ideal of the unstable life,” says Penelope Trunk, the author of “The Brazen Careerist” (Business Plus, 2007), who blogs and lectures on the transformation of the workplace. “He sends the message ‘job-hopping is O.K.,’ ‘moving around is O.K.’”

That is a comforting message, she says, because while Gen Y talks of seeking passion and embracing what is new, that is just brave cover for a less comfortable truth. “The reality is they might prefer one job that would last forever and end with retirement, but that kind of job doesn’t exist anymore,” Ms. Trunk says. “The alternative, the instability, terrifies them. Sean Aiken is an example of how uncertainty and constant change can be O.K..”

No, the job-for-life doesn't exist anymore. That's the reality right now, and maybe forever. But it's a reality based on choices. And those choices have consequences. So execs, if your employees have a mercenary attitude, then you should be asking yourselves what is driving that response. It's not character defects. It's not a few bad apples. And it's not because people were just better back in the good old days.

You get what you give.

Photo: Good and Bad by vees

SOA for SAP

SAP has an interesting message on SOA, if I'm reading Joe McKendrick right on this - you can use SAP's SOA methods while starting out small as a subscriber to their SaaS offering, and then scale up to their enterprise offering later, in what would certainly be advertised as a "seamless transition."

This is precisely the sort of thing that a consistent architecture should allow. Of course, it cuts both ways - you could also (theoretically) move from SAP's enterprise offering to their SaaS offering. Or more interestingly, move to a competitor who offers the same set of SAP-compatible methods.

What, exactly, would prevent Oracle from offering a set of SAP-compatible methods? And who will be the first to try to claim intellectual property rights on a URL? Is http://mycompany.com/services/sap/adduser© right around the corner?

Once there is a significant set of companies who have committed to a particular vendor's SOA methods, they're also primed for another vendor to come sniffing around with a translation layer and lower pricing.

How eBay Scales Up

Here are a couple of presentations giving an overview of eBay's architectural approach and reviewing how the architecture has evolved.

• current eBay architecture (Nov. 2007 presentation via James McGovern)


• more history on the evolution of eBay's architecture (Nov. 2006 presentation)

Of note:

• No session state in application tier (use URL/cookie/scratch DB)


• No business logic in DB & no stored procedures


• Partition everything - if you can't split it, you can't scale it


• Async everywhere via message bus & periodic batch processes


• Everything fails sometime, so all operations must be fault-tolerant

I manage an ecommerce site that has a single centralized DB (I inherited this architecture when I took it over). That single unpartionable DB is a HUGE headache, and eBay's architecture has me thinking... can I get rid of the DB altogether except as a reporting mechanism?

We know we need to be able to split the DB across multiple geographic sites soon. But this DB stores user account information and orders - so, why use a DB at all? Why not store user account info and order info in XML files in the file system, index them with Lucene for searching, and use async messaging to report order info to other systems that need to know (fulfillment, reporting)? I'm simplifying, of course, but in broad strokes this should work and scale very nicely.

Services & Volatility

Quick and dirty isn't what you normally think of wrt architecture, but sometimes it's useful to keep from getting caught in the weeds for too long. In short:

1. Define your information model
2. Define your abstract model (the business objects, as I think of it)
   
3. Define your services and their bindings to the information model
4. Define your processes and their bindings to the services - paraphrasing here, as the language is a bit vague.
   

(from David S. Linthicum's Reference Models and Architectures via James McGovern)

Key point is this: "The core idea here is to place volatility into a single domain, or a place where the use of services (and thus the information) can be defined, and redefined, according to the requirements of the business."

And that's my jumping-off point.

Traditionally this volatility domain has been in application logic (stored procedures, business logic code, and inevitably UI code). My thinking has been moving towards the idea of pushing that volatility domain more to the services. Not the data & transactional services that Linthicum defines as being part of step 3 above. But rather to move the business processes into workflows accessible to the business as services. This would avoid multiple constituencies having to independently wire up the underlying services (data & transactional) and ensure that everyone is using a consistent workflow.


I see challenges with this approach though...

First challenge is that workflows imply that state is being kept because they are asynchronous. You can hand a token to the client that will later let the client pull up the workflow in its current state. But now the client has to store and track that token itself, and handle situations where the state returned from the service isn't what was expected. Maybe I'm expecting too much here, but if you're going to go to the effort of making the workflow consistent across the business, then you really want to do it from end to end.

Maybe a solution would be to use webparts that front the workflow service. Here you would wrap the workflow service in a UI and keep it self contained, leveraging the ability of the webpart to share data with other webparts. And so consumers are stringing together common webparts that they organize in a way that makes sense for their part of the business.

Second challenge is handling the inevitable change that occurs in those workflow services. Maybe you can solve this with versioning for 80% of the consumers, and the rest of the consumers we have to accept have their own specific needs that aren't going to be met by the workflow services and this population of consumers will have to wire up their own specific code against the data & transactional services.

So, webparts (at least in a Microsoft world) fronting workflow services. It's not a bad approach, but those webparts are going to start getting complex... not sure we haven't just traded one problem for another. But still, there just might be something here worth pursuing....

Down on the Cube Farm

With a move to a new office space and low cubicles just around the corner, I am compelled to analyze why I find cubes so noxious and disrespectful...

Maybe it's because I can remember the Microsoft job ads promising an office with a door that shuts for every programmer. They get it, I thought.

Maybe it's because sometimes I need to concentrate - really concentrate - to get every detail stuffed into my brain at one time to solve a problem. That requires a distraction-free environment.

Maybe it's because I really don't want to have to listen to someone else's conversation. Not on the El, not in a restaurant, and not at work.

Maybe it's because I have to talk to other people all the time, and I'm aware of the noise pollution we're creating for everyone else within earshot.

But maybe mostly it's because I think it's Theory X embodied. Employees must be observable at all times or else they will slack off. If you really think these are the kinds of employees that your hiring policies bring in, you really should outsource the entire company to India.

And I'm not the only one:
The Myth of the Collaborative Cube Farm
Firewall your attention at the office
Why Proximity Kills Productivity
Cubicles: The great mistake

Guerrilla SOA is to BDUF as the Internet is to...

Joe McKendrick's post on guerrilla SOA services describes services arising as islands or neighborhoods. Both are nice analogies.

But what does EA even mean in a world of guerrilla SOA? Extending the neighborhood analogy, do you have to burn everything down occasionally in order to get a coherent system? I'm thinking specifically of the experience of navigating my hometown Chicago's post-fire grid system vs. Boston's decentralized and unplanned road system.

Still, I find the guerrilla SOA concept rather compelling. What I like about this approach is:

• It doesn't require perfection up front
  
• Keeps the focus on the business
  
• Abstracts the type system (WSDL) out to a format that can change without breaking clients. The Soya project would be a concrete example of this message-oriented format.