Enterprise Architecture: From Incite comes Insight...

It has now been a full three weeks since I returned from the most wonderful European Identity Conference. In this time period, I received over 3,000 email messages and over 49 voice mails of which all but a small percentage was worthwhile.

The biggest annoyance was all the sales people who first sent an email and then also followed up with a voicemail. If they wanted me to spend time understanding their value proposition, they can now assume that they have been swiftly moved to the bottom of the pile...

The Hartford Chapter of OWASP will be featuring Marcus Ranum, inventor of the firewall for its next meeting on June 10th. The agenda is posted here.

Future OWASP meetings will include Grady Booch, Kent Beck, John Zachmann and other industry thought leaders. To receive an invite, please subscribe to the mailing list located here.

All OWASP meetings are 100% free to attend...

Is all change good?



Are you a fan of Scrum, Extreme Programming, CMMi, ITIL or other hot enterprise trend? Have you ever considered why mediocrity is the norm and why a best practice never really feels best? Do you consider change good but always end up with the wrong kind?

Large organizations are inherently conservative. There are multiple forces in place to prevent change. And when change is adopted, it usually ends up getting bunches of familiar things bolted onto it in order to raise the comfort level of those being encouraged to accept it, thus diluting or reversing its value, so it fails, so the people who resisted then have that as an arrow in their quiver to oppose whatever the next change that comes along is.

Recently, someone asked me for thoughts on developing software within an enterprise environment and I figured I would share my thoughts publicly...



The question was asked of me by a person currently employed by a software vendor so answers will be in this context. Anyway, here are some of the things I think are benefits.

1. The single, biggest benefit is that you have incredible access to your end users - they work down the hall! Additionally, you have complete access to their corporate culture.

2. You know who will be using your software and what they are trying to achieve with it. While requirements may sound abstract, the goal and intent are very concrete.

3. Another benefit is that you may get to work on other parts of the project, rather than just coding. Gathering requirements from stakeholders, run presentations for staff, and if it is a system that clients of your firm will be using then you may get to meet them and get another perspective on the business.

4. One pitfall can be the politics that go into it - since your customers are internal, people can go up the chain and force work back down it if they have something they want done NOW. And if you're not doing it fast enough, they can bring it straight to your manager. Your boss in an enterprise is less likely to serve as a condom than the equivalent of the sales guy in a software company.

5. Standards are lower for anything which is not public facing.

6. You're a developer in a company that probably doesn't want to be developing (and paying for the development of) software.

7. Scope creep.

One of the most frustrating things as an architect that I have experienced in every non-software centric company is the acceptance of bad software...



Why aren't more large enterprises banding together to stop the acceptance of suboptimal software? We all know that BPM and ECM vendors can do a better job of making their products more secure, yet enterprise architects choose to remain blissfully ignorant and let them get away with compromising the business they are supposed to represent.

Doesn't enterprise architecture sometimes require us enterprise architect types to consider not just the software we use, the reduction in the amount of vendors we work with, but to help software vendors develop software that benefits our ecosystem?

What would it take for a few thought leaders to get a conversation going on improving the interactions between large enterprises and their vendors...

While Ruby on Rails isn't being used for major enterprise application development, it has been successful in penetrating pockets of corporate IT. Below are some of the names of large enterprise-class shops that are currently developing using Ruby on Rails:

• JP Morgan Chase
• NBC
• New York Times
• Barclays
• Chicago Tribune
• Orbitz
• Walt Disney
  

I hope to construct a similar list of large enterprises that are currently developing using Smalltalk and not just for maintenance of applications written a decade ago. Stay tuned...

To the managers and customers of this software project:

Article One
You have the right to an overall plan. The team should tell you what they could accomplish in the next year or two, and tell you how much that would cost.

Article Two
You have the right to see progress. From the very beginning of the project, the team should be producing functionality that you care about. The functionality should be in the form of a running system, proven to work by passing repeatable tests that you specify.

Article Three
You have the right to change your mind. As software development proceeds, you should be able to substitute new functionality for old. You should be able to change the relative priorities of the features of the system, dictating what should be done first and what should be done later.

Article Four
You have the right to be informed of schedule changes. Since some things will turn out to be easier than expected and some things harder, the schedule is going to change. You have the right be informed of such changes as soon as the programmers know about them. You have the right to exercise your business judgment by choosing among options for reducing scope so as to restore the original date. You have the right to cancel further development at any time and be left with a useful, working system that reflects your investment up to that date.

Are you within a shop that uses Scrum who seems to always stop short of producing high quality software?



Many shops make the fatal mistake of doing scrum without doing extreme programming. One without the other can only result in mediocrity.

Scrum is an agile project management methodology. It does not address the practices required to create "goods" of any kind, but instead gives us the process that will take us from the inception of a vision to the final product, regardless of the actual development process. The Scrum process doesn't tell you how to create quality. It shows you what the quality is, where your problems are, and challenges you to fix them.

Extreme programing is an agile software development methodology. It gives us a process with which to create software in an agile and productive way. It deals with, though doesn't specialize in the management of the development process, and focuses mostly on the engineering practices required to deliver software, with quality.

When adopting Scrum for the purpose of software development, the engineering practices are imported from an agile software development practices, most often from XP. These practices, are those that can be adopted in a manner that is decoupled from the rest of the development practices. Most often, these practices are: Test-Driven Development, Refactoring, & Pair Programming, and User Stories, though by no means are these required in Scrum, or the only way to do things (just highly recommended). Agile Modeling is another common source of agile engineering practices.

So in short, when mixing Scrum and XP, which is by far the most common mix, you use all of Scrum's management artifacts, e.g. Sprints, daily Scrums, retrospectives, burn down charts, and so on, and add XP's TDD, refactoring, pair-programming and JIT design via User Stories.

Of course, Scrum being Scrum, this is how you start, and you constantly adapt (refactor, if you will) the process to answer your organization's specific needs.

Just because ten thousand clowns in IT write code a certain way, doesn't make it correct. It may make it OK where mediocrity is the norm. Likewise, if you don't learn something new every single day, even stuff distant from your primary job focus, you will never understand the big picture. You will become bored and will start thinking in patterns...

The "Kirkpatrick Model" by Donald L. Kirkpatrick gives four levels of (increasing) competence:

Unconscious Incompetence = you don't know that you can't do it well.

Conscious Incompetence = you know you can't do it well.

Conscious Competence = you do it well, and you think about the work as you do it.

Unconscious Competence = you're so successful it's "automatic" -- you do it well, without thinking about it.

Take mental breaks and listen to the perspectives of other developers...



There's a scene in the movie Pi where the character Saul, an old mathematician, describes the story of Archimedes wrestling with the problem of measuring the mass of gifts given to the King to determine if they have real or fake gold in them. Frustrated, his wife tells him to go take a bath and relax. Archimedes takes a bath and solution occurs to him while soaking in the tub. Displacement of water can measure mass. He famously shouts "Eureka!". Saul finishes the story and asks the other character, Max, what the moral of the story is. Max replies: "that a breakthrough will come". Saul replies "Wrong! Listen to your wife, she will give you perspective! You need to take a bath!".

In other words, brute force rarely works well on finding the solution to vexing problems, but taking a break and discussing the problem with other folks, or even discussing something else, can do wonders for the background processes of your brain.

Many programmers here would agree there are diminishing returns to working extremely long hours and killing yourself while trying to be the hero programmer. Sometimes you just need to take a bath :).

In my career, I have worked for small companies, done consulting, worked on Internet startups and now work in a really large enterprise. The one thing that I have yet to accomplish is to work for a software company...



The next career horizon I need to cross is to find a way to lead an elite team of professionals in the creation of game changing software. Although I have direct reports, for the most part am still an individual contributor. The ideal position would be leading a team of 30 to 50 highly motivated technologists where I could travel (meet new clients on a weekly basis) while avoiding the need to commute (meet the same client every week).

I really like where I currently live and am not interested in moving. My friends and family are here and I see no reason to change this aspect of my life as this is a major component in terms of achieving work/life balance.

I have this burning desire to make this happen within the next couple of years. I have a lot of potential that I can't necessarily use within an enterprise context. Have you ever heard of climbing the corporate ladder? I don't want the ladder, I want the elevator.

Am I being realistic? Does such an opportunity exist? If it were in my face, would I recognize it?

Throughout my career, I have noticed the trend to take junior people in the industry and make them report to a resource manager. The justification is usually to free up the capacity of more senior people within an organization and to not burden them with administrivia. Sadly, there are several side effects to this worst practice...



Having a resource manager affords an organization to ignore the value proposition of building talent and to leverage those who have no other abilities. A junior person without the mentorship of a senior person over time becomes a mediocre junior person who has lots of years of service.

Many of these people believe that they have twenty years of experience when reality may state that they have one year's worth of experience stretched over twenty years. IT continues to practice this insanity yet scratches its head whenever systems crash, IT isn't happy with the deliverables or talent walks out the door.

I wonder why they aren't figuring out what they are doing wrong...

Isn't it sad that the masses don't have enough attention span where 160 character tweets is the most others will read? Twitter is about pontifications where the blogosphere was originally started as a mechanism to have a real dialog that otherwise has never materialized.



For many bloggers, the rationale for why they blog isn't just to share insights on some concept or technology but to find others just like themselves. It is rare to run across folks with intelligence and passion as perception management is now more important than technical excellence and demonstrated ability.

As for the bloggers I follow, I have always gotten the sense that they refuse to be assimilated by the borg of impersonal corporate culture where you are just a number in a capacity plan. Today's IT is plagued by a knowledge crisis that we can't seem to shake, yet is at the root cause of why IT can't ever seem to find alignment with the business. Maybe, we should ask ourselves what would happen if your business customers started to have direct conversations with bloggers and bypassed IT. Even if things didn't get more innovative, the conversations would most certainly be more interesting...

Many enterprises are of the belief that they are adopting agile methods and are piloting the notion of SCRUM. Sadly, along with this adoption comes a worst practice. It should not be assumed that new things must be better than old things...



We all understand that pretty much anything and everything is better than waterfall, but that doesn't mean that agile methods done incrementally will have a different outcome. We have to look at waterfall through the lens of whether it works or not while avoiding looking at waterfall through the lens of it being old.

The age of something does not, in general, have any bearing on its quality or correctness. In the case of tradition, assuming that something is correct just because it is considered a tradition is poor reasoning. For example, if the belief that 1 + 1 = 742 were a tradition of a group of people it would hardly follow that it is true.

Another but often ignored lens in which to view things is through the test of time. In some cases people might be assuming that because something has lasted as a tradition or has been around a long time that it is true because it has "passed the test of time." If a person assumes that something must be correct or true simply because it has persisted a long time, then he has committed an appeal to tradition. After all, as history has shown people can persist in accepting false claims for centuries.

However, if a person argues that the claim or thing in question has successfully stood up to challenges and tests for a long period of time then they would not be committing a fallacy. In such cases the claim would be backed by evidence. As an example, the theory that matter is made of subatomic particles has survived numerous tests and challenges over the years so there is a weight of evidence in its favor. The claim is reasonable to accept because of the weight of this evidence and not because the claim is old. Thus, a claim's surviving legitimate challenges and passing valid tests for a long period of time can justify the acceptance of a claim. But mere age or persistence does not warrant accepting a claim.

So, for boneheads who will get it twisted, I am not attacking agile software development. In fact, I am encouraging it as the focus has to be on what works, not on what is new, what others believe, etc...

Projects often fail when key people leave the project early in its lifetime.” Companies’ modern habit of laying off senior and, thus, higher-paid workers -– such as senior developers –- in favor of less experienced, lower-paid workers. It doesn’t make sense, because the more experienced people take a humongous amount stability, experience with them that usually isn’t available any other place. That hurts a project and hurts a company.

The time lost due to less experienced workers’ mistakes and learning curve probably negates the savings in salaries paid.In a poor economy, companies often make hasty and project-wrecking decisions. Besides layoffs, the recession is leading to other foolhardy cutbacks. It seems obvious that skipping testing is a path to software project failures.

The Hartford Chapter of OWASP will be featuring Marcus Ranum, inventor of the firewall for its next meeting on June 10th. The agenda is posted here.

Future OWASP meetings will include Grady Booch, Kent Beck, John Zachmann and other industry thought leaders. To receive an invite, please subscribe to the mailing list located here.

All OWASP meetings are 100% free to attend...

The conflict between the bean counters, who want to treat the results of your development as assets to be managed and the operations folks who view your product as simply services to be procured creates an environment where truly stupid decisions are taken in the name of compromise or synergy if you prefer management babble...

In has been said that C++ is like an optopus made by nailing extra legs onto a dog, then what is an appropriate analogy for how large enterprises nail extra processes onto agile methods...



The savage practice of hybridization where one can never choose one side of the fence or the other within large enterprises is partly due to the appeal of tradition where it is assumed that something is better or correct simply because it is older, traditional, or "always has been done."

This sort of "reasoning" is fallacious because the age of something does not automatically make it correct or better than something newer. This is made quite obvious by the following example: The theory that witches and demons cause disease is far older than the theory that microrganisms cause diseases. Therefore, the theory about witches and demons must be true.

This sort of "reasoning" is appealing for a variety of reasons. First, people often prefer to stick with what is older or traditional. This is a fairly common psychological characteristic of people which may stem from the fact that people feel more comfortable about what has been around longer. Second, sticking with things that are older or traditional is often easier than testing new things. Hence, people often prefer older and traditional things out of laziness. Hence, appeal to tradition is a somewhat common fallacy.

I wonder what it would take for others to acknowledge that anything that sounds like an attempt to sit on both sides of the table are inherently flawed. While I have always stated the believe that incrementalism is a mental disorder, have others acknowledged that adoption of agile methods may suffer from the same fate? So, if an enterprise is being incremental in their rollout, isn't this kinda like expressing the intent to make chocolate chip cookies but later deciding to leave out the chocolate chips? One could argue whether you have cookies at all...

Kiva is a non-profit website that allows you to lend as little as $25 to a specific low-income entrepreneur in the developing world. You choose who to lend to - whether a baker in Afghanistan, a goat herder in Uganda, a farmer in Peru, a restaurateur in Cambodia, or a tailor in Iraq - and as they repay the loan, you get your money back.

Check out the OWASP lending team, and learn more about lending teams on Kiva in general, by clicking here.

I haven't had anyone yet join from Cognizant, Credit Suisse or Cigital...

1. Don't put your resume ahead of business requirements. While career building is important, having unwavering integrity is more important.

2. Architecting is all about balancing. Don't get it twisted and think of it as a pure discipline while ignoring the artful aspects.

3. You're negotiating more often than you think. Just because some negotiations are easier than others shouldn't get you down.

4. Architects must be hands on. Nowadays, there are simply way too many incompetent architects. In order to enable the strategic intent of the business, you must be competent. In order to be competent, you must be hands on.

5. Challenge assumptions, especially your own. We all learn from mistakes, so make a few, but more importantly reflecting on how things can be better.

6. If there is only one solution, get a second opinion. The best architectures emerge from the chasm called choice.

7. Make a strong business case. Speaking in the language of the business isn't about vocabulary as much as it is about being a fiduciary.

8. You can't future proof solutions. You can however design against backtestable worst practices. History is doomed to repeat itself but don't let it happen on your watch.

9. Great software is not built, but is grown organically.

10. The marketplace doesn't need huxsters wearing zoot suits, but the business will always need passionate problem solvers.

How do you garbage collect or eliminate outdated and cumbersome methodologies that are more detrimental than helpful to the software development process? Most methodologies used in IT are all about closing a thousand barn doors because of the escaped horses of yester-year? Of course, we don't want history to repeat itself but we also need to be forward thinking.

Have you met individuals within your organization that have made a career out of being an impediment? This can be manifested as being the skidmark on the fabric of IT or even more subtle such as answering on the specific question that you ask...



Sometimes, the reason for being an impediment is that this individual is proud of their knowledge and probably derives pleasure from being the sole keeper of truth. Try giving this person the "respect" he craves. Treat him like a guru. Tell him you see him as your mentor. In that capacity, perhaps you can ask things like "I want to learn everything about this message and only you can help me. Can you please steer me right so I don't run into traps?"

I know this sounds a little "help me Obi-wan Kenobie, you're my only hope." There may indeed be no hope. But invoking the ego sometimes works. Likewise, keep asking questions. Ask so damned many questions that he can't get anything done but answer your questions. He'll either complain about you, or he'll start giving you more information just to shut you up.

My thinking says that if we all believe in the time honored principle of people, then process, then tools - in that order, enterprises tend to skip past the people and immediately focus on process which results in mediocrity. I was also noodling the fact that even if we were to focus on people, no one has been taught in their careers as to how to focus on people and therefore mediocrity is guaranteed.

So, if you want to roll out agile methods for either project management such as SCRUM or something focused on software development such as Extreme Programming, the enterprise needs to start thinking about people and more important which people to focus on. When kicking off agile methods, it shouldn't be about the organization chart nor be constrained to traditional influencers but you must start with identifying the innovators, the early adopters and the early majority as your starting point.

To classify people in this manner would also call out those who are part of the late majority and the laggards. The innovators, early adopters and early majority should be the target audience and hopefully you can identify enough of them to reach critical mass.

Guy Kawasaki has a term that I find amusing which he refers to as the Bozo Explosion, many folks attempting to roll out agile simply have too many elephants in the room. Trying to eat one elephant is challenging but putting multiple in the same room each with their own whim, screeds and rants is essentially futile.

Agilists sometimes make a common repeatable mistake of thinking that logic will prevail while forgetting that others they are attempting to bring into the fold are human and come with baggage that we can't simply ignore. Maybe they need to be reminded to also focus on people, then process, then tools in that order...

For doing the mundane well on a day to day basis, it is good to recognise the developers effort verbally to them. An honest thank you that mentions the specific behaviour and its positive repercussions to you personally will be well received, adjust the language to suite each individual. (Note that other developers within earshot may also respond to this by increasing their efforts in this specific activity.)

How come managers are noodling the following:

• Formal written (email) acknowledgment and praise to senior managers of the teams efforts and successes. (Note that acknowledging individuals alone may damage team spirit)


• Work the hours you expect your team to do. If they absolutely must work late for a deadline, be there in support Go to bat for the team. Refuse to let them be forced to work long periods of overtime without compensation.


• Protect them from level politics and stress.


• Give your team the best equipment you can afford. Good tools show respect and improve productivity. While you are at it, kidnap the clowns who think that developers should have the same desktops as everyone else.

I am just returning from the European Identity Conference where I had some great conversations with thought leaders in our industry. Over the next week, I hope to share insights and continue the dialog I had with many virtually. Today, I wanted to focus on an intersection of conversations I had with Kim Cameron, Vittorio Bertocci, Dee Schur of Oasis and Anthony Nadalin of IBM, Prateek Mishra of Oracle on what are some of the next steps that need to occur to make cardspace usable in a B2B setting...



Consider a scenario where you are an insurance carrier and you would like to have independent insurance agents leverage cardspace for SSO. The rationale says that insurance agents have more personally identifiable information on consumers ranging from their financial information such as where they work, how much they earn, where they live, what they own to information about their medical history, etc. When they sell an insurance policy they will even take payment via credit cards. In other words, if there were a scenario where username/passwords should be demolished first, insurance should be at the top of the list.

Now, an independent insurance agent can do business with a plethora of carriers whom all are competitors. The ideal scenario says that all of the carriers would agree to a common set of claims so as to insure card portability. The first challenge is that the insurance vertical hasn't been truly successful in forming useful standards that are pervasive (NOTE: There is ACORD but it isn't widely implemented) and therefore relying on a particular vertical to self-organize is problematic.

The business value while not currently on the tongues of enterprise architects who work in the insurance vertical says that by embracing information cards, they could minimally save money. By not having to manage so many disparate password reset approaches (each carrier has their own policies for password history, complexity and expiry) they can improve the user experience. Once this demographic decides to not remain blissfully ingorant and start to develop an uderstanding that being a really could relying party can make IT cheaper in the long haul and in a way that business people would understand.

If I wanted to be a really good relying party, I think there are other challenges that would emerge. Today, I have no automated way of validating the quality of an identity provider and would have to do this as a bunch of one offs. So, within our vertical, we may have say 80,000 different insurance agencies whom could have their own identity provider. With such a large number, I couldn't rely on whitelisting and there has to be a better way. We should of course attempt to define what information would need to be exposed at runtime in order for trust to be consumed.

One analogy that I think has merit is in thinking about how PKI works. If you receive a certificate, the very first thing you do is to figure out if it is signed by a root CA that you trust. The same thinking could apply to an identity provider where if I received a pointer to an identity provider that was signed by a state department of insurance that I trust, then why wouldn't I want to trust it. I could upfront populate my RP with a listing of trusted roots and then could essentially consume identity without ardous registration processes while also avoiding whitelisting maintenance overhead.

The second challenge in been a really good relying party is to understand the vetting process of an identity provider. Today, there are notions of identity assurance within several of the OASIS specifications but the thinking is not complete. For example, don't you think it would be important for a relying party to understand method was used in identity vetting and to what level? For example, vetting can occur based on several mechanisms including out-of-band confirmation, knowledge-based authentication, in person and so on.

For knowledge-based authentication, wouldn't it be cool if one knew that a subject faced say five questions and got all five right vs say only three? Some of the other questions may include a way to communicate when the vetting process last occured, kinda along the lines of the way that IdM types think about attestation. Taking this one step further, Wouldn't it be great if the identity provider could also provide some form of how strongly or weakly they guarantee their own vetting? If an IDP could communicate that bad identity would be indemnified at a dollar value vs no liability/responsibility, the relying party could make an informed decision.

Anyway, wouldn't it be much better if a relying party could somehow communicate that they only wanted to accept cards that were signed by a particular body they trust and that was also vetted to a level they were comfortable with where the identity selector not only understood this request, but also only presented cards that met this criteria?


So, as I see it there are several action items that need to occur:

1. Microsoft needs to redouble its efforts to sell information cards as a business value proposition where the current pitch is towards a technical audience. It is nice that it will be part of Geneva but this means that its capabilities would be fully leveraged unless it is understood by more than folks who do just infrastructure work.

2. Oasis is a wonderful standards organization and can add value as a forum to organize common claims at an industry vertical level. Since identity is not insurance specific, we have to acknowledge that using insurance specific bodies such as ACORD may not be appropriate. I would be game to participate on a working group to generate common claims for the insurance vertical.

3. When it comes to developing enterprise applications using the notion of claims, says that developers need to do a quick paradigm shift. I can envision a few of us individuals who are also book authors coming up with a book entitled: Thinking in Claims and XACML as there is no guide to help developers understand proper architecture going forward. If such a guide existed, we would repeat the same mistakes of the past.

4. I am wildly convinced that industry analysts are having the wrong conversations around identity. Ask yourself, how many ECM systems have on their 2009 roadmap, the ability to consume a claim? How many BPM systems? In case you haven't figured it out, the answer is a big fat zero. This says that the identity crowd is evangelizing to the wrong demographic. Industry analysts are measuring identity products what consumers really need which is to measure how many existing products can consume new approaches to identity. Does anyone have a clue as to how to get analysts such as Nick Malik, Gerry Gebel, Bob Blakely and others to change the conversation.

5. We need to figure out some additional identity standards that an IDP could expose to an RP to assert vetting, attestation, indemnification and other constructs to relying parties. This will require a small change in the way that identity selectors work but B2B user-centric approaches won't scale without these approaches...

I think Scrum is easier to accept for the old-scientific-style of management than any of the agile methods out there...



As with most things agile.. I think the fault lies in

• not understanding the principles behind the methodology... leading to following listed practices on blind faith.. and helplessness when they don't work


• not adapting the methodology to the problem at hand. Standardizing is just so tempting.. chasing Templatized solutions for all problems. 'this is our new process. Everyone shall comply.'


• not adjusting to ground realities and retrospectives.


• Fixing symptoms rather than the disease.

Good people will make good software (even without agile, SCRUM, or whatever)... mediocre and lower people will churn out similar software even with their home-grown variety of agile. However people doing agile as it was meant to.. will result in better products.

I usually hate productecture oriented commentary but figured I would comment on Oracle and their showing at the European Identity Conference. I had the opportunity to talk face-to-face with Christian Patrascu, principal product manager or Oracle Fusion Middleware and John Aisien, VP of Product Management for Oracle Fusion Middleware and was impressed by their thoughtfulness, candor and integrity. In conversations with them, they were diplomatic, didn't use the usual Gartner-style bullshit buzzwords and can talk at both a high-level (CIO babble) as well as techno geek.

At the European Identity Conference, they had the best booth and gave out embroidered custom hats and were the most engaging. The talent in the booth had others beat. I currently own Microsoft stock and am consider taking up a position in Oracle stock because of the collective vision represented by them...

There is a school of thought which says that any sort of individual rewarding promotes competition among team members at the expense of the team losing sight of the overall team focus/goal...



When can we acknowledge that in order to have top talent you have to have inspiring top talent within leadership? Compensation isn't a substitute for incompetent leadership direction. If you reward folks for perception management or just delivering on time, then what kind of message are you sending?

If you give rewards, then someone is not receiving it and that is bad for motivation. But if rewards should be given, it should be to the whole group (or company if its a small one). I think the negative side of reward giving is bigger than the positive in the long run.

It goes without saying that as an individual, I prefer individual rewards because of my ability to at least have some control over them. Likewise, if I put on my manager hat, I immediately switch to preferring team rewards because it gives everyone an incentive to not let down the other members of the team along with countering the personal self-serving motivation that taints most IT organizations.

     Drug Dealers                      Computer Programmers 
     - Refer to their clients as       - Refer to their clients as 
       "users".                          "users". 

     - "The first one's free!"         - "Download a free trial version…" 

     - Have important South-East       - Have important South-East Asian  
       Asian connections (to help        connections (to help debug the 
       move the stuff).                  code).

     - Strange jargon: "Stick,"        - Strange jargon: "SCSI," "RTFM," 
       "Rock," "Dime bag," "E".          "Java," "ISDN". 

     - Realize that there's tons       - Realize that there's tons of 
       of cash in the 14- to             cash in the 14- to 25-year-old 
       25-year-old market.               market. 

     - Job is assisted by the          - Job is assisted by industry's 
       industry's producing newer,       producing newer, faster machines. 
       more potent mixes. 

     - Often seen in the company       - Often seen in the company of 
       of pimps and hustlers.            marketing people and venture 
                                         capitalists. 

     - Their product causes            - DOOM. Quake. SimCity. 
       unhealthy addictions.             Duke Nukem 3D. 'Nuff said. 

     - Do your job well, and you
       can sleep with sexy movie       - Damn! Damn! DAMN!!! 
       stars who depend on you. 

Many enterprise architects think that their ideas are absolutely brilliant. Too bad most of them have never attempted to put a dollar value to them...



Gunnar Peterson always suggests that architects think in terms of dollars and sense but has never proposed a way to calculate it. So, here is a formula that is applicable and borrowed from 37 Signals.



* Awful idea = -1
* Weak idea = 1
* So-so idea = 5
* Good idea = 10
* Great idea = 15
*

Brilliant idea = 20
*

No execution = $1
* Weak execution = $1000
* So-so execution = $10,000
* Good execution = $100,000
* Great execution = $1,000,000
* Brilliant execution = $10,000,000

To make a business, you need to multiply the two. The most brilliant idea, with no execution, is worth $20. The most brilliant idea takes great execution to be worth $20,000,000. So, instead of focusing on brainstorming and perceptions around it, why aren't enterprise architecture practitioners more focused on strategic execution? I'm not interested until I see their execution.

I have talked to authors who say they don't care about people giving them credit, they just want people to use their code. Public Domain would make it easier for people to do so...



So, we all agree that being open is good then why are we still have stupid debates over licensing terms such as BSD vs GPL? The first thing that impedes being truly open is the need for feeding of egos. Authors typically don't want usage of the code restricted but they also want credit for creating the code which becomes its own impediment.

Likewise, since we open source developers allowed lawyers to participate and twist the understanding of what we wanted to achieve, we made it damn near impossible to do any release of code in a legally binding way. In the US all works are automatically given copyright.

So, if everything is important, what is more important? Use of code or constraint of how others use code? If you release some code into the public domain, anyone else can take that code, modify it slightly, and then release it under their own license, which can be as restrictive as they wish.

I wonder if we could get lawyers working on the problem of public domain where only a license prevents people from suing you if your uber-routine ends up killing someone's favorite dog...