Enterprise Architecture: From Incite comes Insight...

The Hartford Chapter of OWASP will be having some really great speakers for its September and October meetings. I am anticipating that I will need to find larger facilities as our current space only accommodates 100 people. Anyway, if you haven't had the opportunity to attend one, you don't know what you are missing.

If you are a software vendor or consulting firm and are interested in speaking/sponsoring one of our meetings, please do not hesitate to drop me a note...

Below is a transcript from a fictitious interview. I would love to know if you would hire this person and reasons behind your decision...

HR: What's your favorite programming language?
CANDIDATE: You mean the one I'm the best with?
HR: Not necessarily, let's say you have a personal project at home.. which language would you chose?
CANDIDATE: Why would I want to work at home?
HR: You never code at home?
CANDIDATE: No, why?
HR: Have you ever worked with the cogwipCookieManager class, if so, what do you think of it?
CANDIDATE: I've used it before, it works pretty well.
HR: What are the benefits/reasons for normalizing the database used by an application?
CANDIDATE: Performance. The application will run faster against a normalized database.
HR: In what situations should denormalizing the database be considered?
CANDIDATE: When you need more performance, the application will perform better against a denormalized database.
HR: Do you know ActiveX?
CANDIDATE: Yes I do.
HR: Do you know ActiveZ?
CANDIDATE: Yes I do.

Who cares about being green or global warming? I did this before it was popular. I garden organically, I compost, etc. I wish I could add some of the so-called best practices I hear others speak about. It would make for great fertilizer.

Status updates are not conversation. Folks have abandoned the blogosphere for Twitter. I guess I must follow the crowd. After all, I am learning how to talk like a modern IT executive. 140 character soundbites.

India outsourcing is actually embraces agile even though it appears as waterfall. The practice of three or four Indians huddling around a computer, barking out ideas and one guy banging away at the computer until something works is the norm.

How can SOA be dead if it were never alive in the first place? Most shops that thought they were doing SOA were actually doing overly complex network-oriented component modeling at best. SOA was stillborn.

Here's a revelation, enterprise architecture is also dead. Most shops are no more mature today than they were say five years ago.

At least open source is thriving. Maybe it is because enterprises aren't participating? Have you seen some of the code that enterprise developers write? Think taint.

Why haven't developers realized the value of OWASP? Learning about web application security isn't just about some initiative such as PCI, but is something that can save your career?

How much innovation has there been in the world of BPM in the last five years? Now ask yourself how much innovation is in the world of ECM? If there were a way to measure innovation across domains, ECM would surely lag others.

The suckage factor of industry analysts continues to increase. I wonder if interoperability should be constrained to just products or whether industry analysts should do something more to enable interoperability amongst customers?

Did you know that India didn't even rank in the top 15 finalists of the 2008 TopCoder Competition?

I like Creative Commons but wouldn't it be great if being creative were common?

I hate the fact that folks refer to Java as being open. Java is not even an open specification. The language itself is controlled by Sun and not any standards committee. Who cares where source code to the VM is available or not.

There are more open source projects from Scandanvia than all of India

Wouldn't it be great if Novell open sourced Netware OS?

How about a revival of Banyan Vines

Anyone else notice how the identity crowd is fearful of XACML? I don't think it is just because of it being a different problem space but more because their own products and roadmaps suck and they can't pull it off

How come no one in the OpenID community has enough integrity to state publicly that while they got something to work, it is simply a bad idea to use it for anything meaningful?

I really would love to see Geneva support OpenID though. Maybe Mike Jones, Kim Cameron and others can talk about incorporating OpenID support into Geneva as both an IDP and RP.

I believe that the best way for survival of the US is to focus on lowering of real wages for IT professionals. Today, way too many folks in IT get paid for false leadership and perception management. In order to be competitive, we have to focus on innovation and start measuring each individuals contribution towards this goal.

Gunnar Peterson frequently points out the fact that most IT security professionals are an impediment to true security due to their lack of background in software development. The answer I seek is tips and techniques that will help those who are impediments to progress to realize this fact in a timely manner and step out of the way.

Its 2009 and hype is still the plaque on the house of software and we are trending worse.

Let's face it. Most IT shops have no real leadership to speak of. The key question to ask is when will they stop thinking that their management is leadership and come to reality.

CMMI is finally starting a slow and gradual death spiral. At least enterprises are starting to realize that process isn't a substitute for competence.

I bet the CISSP and PMI crowd will churn on this blog post. Anyway, here are ten things to consider...



1. security risk is quite different than business risk that consists of forecasting of investing resources to produce a profit. It also has no relationship to IT risk that forecasts probabilities that new enterprisey product you purchased and would like to implement using Indian outsourcing will be financially successful (we know that technical success is mediocre at best when outsourcing).

2. Security risk management has never been demonstrated to be valid. No study has ever been published to demonstrate the validity of information security risk assessment, measurement, and control based on real experience.

3. With rapidly expanding regulations, risk is transforming from risk of rare incidents to risks of failure to meet the regulatory requirements and the impacts of penalties that might ensue.

4. Top management underfunds, undersupports and underrepresents information security is because information security is represented to management as being based on intangible risk reduction that is easily refuted or ignored. Risk reduction is a weak justification for security.

5. Information Security Practitioners should show that they are following industry-wide best practices for processes, controls and monitoring. Constant education and networking will be required to maintain this state. If the vast majority of modern attacks are all about web application security, how can so many IT security departments not even have a clue about OWASP nor even send at least one of their members for representation purposes?

6. Ask a CISSP how they would have calculated risk of a terrorist attack on September 10th or whether an airline should have purchased secure cockpit doors. They did exist, why didn't airlines own them? Was it because of risk?

7. Security isn't hard. It is actually easy. Is there more risk when you apply your CMMI level 13 antiprocess layered on top and it only takes someone with kindergarten competence ten minutes to break in. I once hacked into a bank with an Abacus while riding a skateboard backwards in a snowstorm. This isn't ridiculous. Your focus on process is. Process is not a substitute for competence.

8. Why is security something treated as a black art. It isn't special, it simply requires about ten minutes more time than the average IT executive spends in order to understand. It has to become part of your job. No processes, no checklists, etc. Kinda like using toilet paper after you create another sticky idea. There is lots of risk if you don't think about it this way.

9. Are you annoyed with security professionals who pontificate with humorless monotone legalistic rambling that no one understands? How can other understand risk if they don't even understand what you are saying? Who cares if security is aligned with the business, how about security folks learning to communicate like other humans? Throw out all those policies that no one reads nor understands.

10. July 4th 2009 is when I not only declare that I will be retiring from the blogosphere but will also declare that security will become irrelevant. The bad guys are winning and the good guys just don't have a long enough attention span to win. I am taking my ball and going home.

I am off to the races to be the first to hack into a major corporations mainframe with a butterknife and some twine. I wonder if I twitter it, will someone hire me as their next CTO as your enterprise is doomed unless you realize that risk is nothing more than a four-letter word for perception management. To mitigate risk you have to focus on reality and the best way to do so is to keep it real...

Ever been a part of a crisis where IT executives are coming out of the woodwork looking to throw someone presumed guilty under the bus? I wonder if this behavior is leadership or simply suboptimal management...



Enterprise Architects see things through a longer term lens than most of IT. Would you want to use or maintain a piece of software designed and written in a state of mind as if under continous attack from a mammoth?

I remember my days in the Coast Guard when Seaman Big Crow used to outrun me with a heavy pack. The pressure to excel physically is guaranteed when under pressure and this tactic has on numerous occasions been applied to the world of sports and other pursuits that involve physical labor. However, it is almost certainly guaranteed to backfire when applied to the world of IT within a large enterprise.

An important time-management and stress-management technique is to set priorities, and then address each task in a focused-but-unhurried manner. You can never do everything you want (or even should), so focus on the tasks that have the biggest payoff. Trying to "work harder" doesn't pay off.

My current state suggests that I am not only an architect but have several others reporting to me which means for me to be a true leader, I have to not repeat worst practices made by others. The first worst practice is in not acknowledging that people think differently when under pressure. They may be more focused, but they're not necessarily focusing on everything that needs to be done. Pressure places people in a specific mindset, and that can have massive repercussions. This is why stupid bugs can get introduced during peak development times, because folks are in that anxious, sharp-minded time when they're focusing on specific things, but not necessarily all the important things.

People can be more productive for a short time when under pressure because they (a) focus attention on the important tasks and (b) ignore low-priority tasks. Of course, this requires us manager types to provide the right support to those in a crisis and help them understand that while everything is important, some things are more important.

Gunnar Peterson: You have met many architects, CISOs and others in the security community but have never commented deeply/frequently on what successful individuals in this space all have in common? Could you make your next blog entry on this topic and include how enterprises can recognize talent from within especially as they start the journey towards application security?

Brenda Michelson: Each industry analyst firm pursues its own customer base and develops its own approach to analysis and research. Some of the analyst firms I interact with have briefings with enterprise customers that last a half-hour while others go an hour. Should customers ask themselves for the firms that schedule half-hour briefings, are they doing so because they don't have one-hour's worth of content? Could you make your next blog entry on what enterprise customers should consider when purchasing analyst research?

Todd Biske: I can count the number of peer enterprise architects from Fortune enterprises who are credible bloggers on one hand and I must say that your blog is the gold standard in this regard. Could you make your next blog entry on the topic of why you blog but more importantly provide a sense of why in a way that will encourage some of our other industry peers to come out of hiding? Please also share what other topics are of interest to you besides SOA? Curious to know if you have drunk the Kool-aid on $$$$ ECM technologies that really should cost $ or whether you have ever attended an OWASP meeting, etc?

James Governor: When I first heard about the notion of open source analysis I felt liberated. The ability to participate, influence and consume content created, vetted and stewarded by the community at large was a rebirth. When Redmonk produced their paper on Compliance Oriented Architectures (COA), I cried tears of joy knowing that you and Stephen did something that could never be accomplished by the 1984 humorless monotone culture of Gartner. Don't let the idea die on the vine and instead figure out its next incarnation. Could you make your next blog entry on Open Source Analysis 2.0?

Jordan Haberfield: You recently spoke at the Hartford Chapter of OWASP and provided insight into what it takes to become elite IT talent. Your message needs to be heard within other OWASP communities as you addressed a dimension of security that is more personal, more human. Anyway, could you make your next blog entry on the topic of recruiting elite IT security professionals and while being a niche, what your customers desire in the way of security talent and most importantly, a few pointers for unemployed American's on how to keep their spirits up in these troubling times.

Isn't it fascinating how much the media has focused on the death of Michael Jackson? Imagine what would happen if they put the same effort into covering the death of our troops in Iraq and Afghanistan or making poverty history by sharing stories of those who participate in Kiva...

George Alexander asked me for a posting that addresses a few questions before I retire from the blogosphere...

1. I always wanted an exhaustive checklist to measure myself against. What do you feel Indian developers (or whatever you may want to call them) need to change/adjust (professionally, culturally, mentality etc) when they come to the US to work with American developers?

I believe the following things need to occur:

1. Professionally: The focus on not just university curriculum but learnings of a professional nature are in order. Participate in local user groups in topics that are of interest to you. For example, if you are into software development, there is no reason why you shouldn't be religiously attending OWASP meetings. If a chapter doesn't exist, then create one. Being a professional requires a code of ethic and outside of work pursuits of industry knowledge.
2. Culturally: Get ready to be shocked. I think very little in this regard needs to change. In fact, I would probably say guard your own culture from suboptimal western influences. Don't allow perception management to enter the decision making process and stay focused on making decisions based on informed fact-based judgment. The Indian culture in many ways has characteristics I would love to see happen in America ranging from the modesty of how women dress to the point that music isn't all about sex, drugs and money. Culturally speaking, don't loose your culture.
3. Mentally: I think tradition is somewhat distinct from culture and I would encourage those who have mental handcuff's to consider alternatives which it comes to things like charity, tipping, not knowing how to say No and inheriting the religion of one's parents. India has its own traditions around Judaism, Christianity and Islam that if folks removed their blinders would see the beauty within.
   

2. An exhaustive checklist to measure your competitiveness as a developer

1. Working on maintenance projects handed to you by American companies will indoctrinate you into worst practices. The less talented developers in America have created unmaintainable balls of mess and have simply thrown it over the wall to India. If all you do is read the worst of our code and have freshers fixing it, it will serve to only taint the next generation.
   
2. You are truly competitive when you start contributing to open source. Don't just use it, but encourage your employer to allow employees to spend company time giving away high quality code for absolutely free. It will make you a much better developer than what is current indoctrination.
3. Encourage more free thinking. Using CMMI to turn everyone into a mindless process weenie is detrimental long term. We need new thinking and India has the potential if it could figure out legal ways to throw those process weenies off the roof. Developers in India should lead the revolt.
4. Start attempting to answer questions asked by American's within online forums. Wouldn't it be cool if Indian's started solving problems that senior American people could figure out on site such as StackOverflow?
5. Learn to write secure code and stop attempting to think of this as an extra chargeable service. Indian outsourcing firms should empower their developers to do an even better job for their clients by putting tools such as Ounce Labs on every developers desktop without the client even having to ask for it.
6. To be a better developer, you have to expose yourself to alternative ways of thinking. Participation in the blogosphere is one method which you have already taken steps to beat out the rest of your peers.
7. Diversify your friends not only at work but at home. You need to be exposed to perspectives that are unfamiliar to you. If you only work with or hire people who are from your same state, then you are missing out on the ability to be truly successful. Consider hiring more females if you are male, or more Christians, Muslims, etc if you are Hindu or more Hispanics, Africans or those not like you. Diversity in your outside of work network is especially important. Look at your family tree and figure out ways you can turn members into a Benetton Poster.
   

In the days past when IT was filled with folks who practiced their craft with passion, moral was high and life is good. Today, with the advent of outsourcing, more non-technical employees in IT than technical and the rise of the focus on soft skills and perception management, focusing on blaming others is rampant. Here are a few ways you can deal with others that behave badly and try to throw folks under the bus...



In my travels, I have met lots of good people that are hard working, honest and accepts their mistakes. Nowadays, those who stand by their word are sometimes blamed for things they haven't done. The bar of what constitutes a valid reason for blame is constantly being lowered. The health and well-being of others in this culture is deteriorated to the point where the masses are popping pills for high blood pressure or other ailments, yet this can be rationalized as casual cliches that roll off the tongue such as perception is reality.

I believe perception management is important, but focusing on the human condition to be more important. Are you in the matrix where folks have forgotten the fine art of blaming oneself first? Is management pretending that they are leadership by allowing a culture to fester where someone or something has to take the blame? If we learn to look for causes of problems without looking for scapegoats, we may learn a way to convince our ultimate customer no to blame everything that goes wrong within an IT ecosystem on technologists.

One tactic that seems to work in some shops is to avoid blame by being absent. Consider that blame is usually spread whenever a hard decision has to be made late in a project due to problems with quality. The tradeoffs usually involve either shipping a sub-standard product on time or delaying the ship date in order to solve the quality problem. Both answers in a perception management culture will create negative impressions. The correct choice is difficult to determine but making the wrong one will have an impact on your career and compensation.

You cannot share in the collective blame of making the wrong decision if you are not present when it was made. It is best to position yourself where you can leverage hindsight which is always 20/20. When it becomes clear which decision was the correct one, you can support it retroactively. Practice phrases such as Obviously, I would have voted to ship late. I only wish I had been present for that crucial decision. I was shocked to find Lucas had decided to ship what was obviously a sub-standard product. You will of course reverse this if required.

This approach can be even more effective if you are absent at the beginning of the project. If it fails miserably, you can claim that you knew the project should never have been initiated in the first place. If it succeeds, it's only because you were brought in to save it.

Another approach is to get yourself deeply involved in other projects or business development activities, and then claim that you are just too swamped with other higher priority projects to worry about the one that is in trouble. With skill, you can shift priorities around and ensure that whichever project is in the most trouble at any point in time will have the lowest priority.

A response to Kim Cameron on Information Cards in Industry Verticals...

When Geneva is released to manufacturing later this year, it will be seen as a fundamental part of Active Directory and the Windows platform. I expect that many programs will then start to kick in that turn up the temperature along the lines James proposes.

My only caution with respect to James’ argument is that I hope we can keep requirements simple in the first go-around. I don’t think ALL the capabilities of claims have to be delivered “simultaneously”, though I think it is essential for architects like James to understand them and build our current deliverables in light of them.

I think I have several reactions:

• Enterprise Architects tend to think more strategic in nature (or at least they should) so tactical current state leanings are sometimes challenging to swallow. What makes them more appealing is if their considerations posed become visible on roadmaps, blueprints, etc by their business partners. Otherwise, the general EA reaction to being tactical is the pain that will emerge down the road.
• I hope that one of the programs will be to actually address how Information Cards can be used within an Industry Vertical context. We have to acknowledge that many of the consortium models are busted when it comes to enabling community formation. More importantly, the message behind identity is confused. On one hand, we talk about separating identity from our applications and then yet we want to constrain it to a vertical context. Maybe the best solution is for Microsoft to introduce me to others in my vertical that have a clue about identity and observe the conversation.
  
• The one entity that I have seen get the convergence of technology and an industry vertical right is IBM. Many of the folks in the insurance vertical have adopted the IIA model for their data warehousing initiatives. Maybe MS can borrow from the IBM playbook and apply it to the world of identity (unless Anthony Nadalin has already started on this journey)

• I fully agree that not all the functionality of claims need to be delivered simultaneously. I do however believe that the next challenge that needs to be tackled is the ability to gain additional insight into the practices of an IDP, otherwise the conversation on the level of business trust goes nowhere. How about some brainstorming on the following?
• How should an IDP indicate that they are storing and possibly correlating activities of an RP to the RP? For example signon.com and myvidoop.com keep track of everytime I touch an RP?
• As you can imagine the insurance ecosystem has hundreds of thousands of potential identity providers and any approach based on manual approval or even whitelisting will not scale. The only method that could possibly work is when we can somehow indicate that we will trust IDPs who are vouched for by higher-level entities we trust.
• There is some adoption of OpenID and I would therefore not want to ignore its usage for low-value interactions. It would be great if Vittorio Bertocci or other MS Bloggers could tell me how OpenID could be supported / extended via Geneva.
  

The rant regarding PCI continues and some of it has merit, however I believe we need to analyze the thought processes of those forced to comply for flaws and throw daggers at them...



PCI tells you what to do but not how to do it. Likewise many guidelines such as NIST RBAC tell you what to do but not how to do it as it should be. In the same way that the Chairman of the Joint Chiefs of staff doesn't deliver your milk, it requires us to acknowledge whose responsibilitiy it is to figure certain things out.

The notion of being spoonfed anything and everything in nice bite-sized chunks will almost always result in missteps in misspending and of course increase risk. Some within the blogosphere believe that auditors need to be held more accountable where at some level agree. I do believe that auditors need to be held to higher standards which implies higher competence which is distinct from accountability.


Enterprises need not only Chief Information Security Officers (CISO) but also wise technically-savvy Chief Security Architects that will acknowledge the the role of an auditor should be to help you assess the risks to the ecosystem where it is your accountability to decide how to secure it, secure it accordingly, check that a minimum number of effective controls are in place and where possible adhere to industry standards.

Many dinosaurs within IT have a romantic infatuation with Smalltalk and still refuse to acknowledge that the marketplace has declared this language the stepchild...



When Smalltalk was introduced, it was too far ahead of its time in terms of what kind of hardware it really needed. Analogous to BSD, Smalltalk made many of the same fatal mistakes. In 1995, when Java was released to great fanfare, one of the primary Smalltalk vendors (ParcPlace) was busy merging with another (Digitalk), and that merger ended up being more of a knife fight.

Other challenges include the almost forced image environment that are freakin huge. Smalltalk has priced itself out of the market and to this day is more expensive on a per-seat basis than other languages. Libraries are not the same between vendors so you suffer from vendor lockin.

As a book author, I can tell you that the classic C book is from K&R, but have no freakin clue as to what it is for Smalltalk. How come no one has thought about incorporating support for user-centric identity into Smalltalk? Can you support Cardspace and/or OpenID?

Ignoring the fact that Smalltalk is the closest commercial language to pure OO and is elegant in this regard, it is simply easier for a newbie developer to learn Java...

The term Tech Lead is starting to appear on the tongues of many large enterprises and has been categorized as a way to call out senior developers. For the role to have true meaning, we have to acknowledge that a tech lead is more than just being knowledgeable about technology...



If you are in this role and want to live up to your title, then you need the following skills:

• Accountable - The buck stops here, someone who can shoulder the responsibility without pointing fingers at others.
• Adaptable - Life changes fast, if can't change with the times, you'll be left behind.
• Approachable - their team can ask them questions and talk to them.
• Attentive - they actually listen to their team and understand them.
• Aware - they're aware of what is going on around them instead of sticking their head in the sand.
• Can type - No hen peck typists need apply in this industry.
• Charismatic - People have got to want to listen to you.
• Communicative - You've got to want to communicate with your team.
• Competent - You've gotta know your stuff.
• Confident - If you're not confident in yourself, how is anyone else going to be?
• Decisive - can make decisions themselves and be accountable for them.
• Driven - You've gotta see the goal and go right after it.
• Focused - You've gotta have the staying power to keep going and reach the goal.
• Inspirational - this is the most important one for me! If you can't inspire people, what are you doing?
• Meticulous - The truth is in the details.
• Nurturing - The test of a good teacher is when their students surpass them.
• Resourceful - You've gotta be able to find the answers to the things you don't know.
• Technically minded - In this industry at least.
• Understanding - If your team don't think you understand them, they won't bother trying to understand you.
  

As a leader, it's your delegates that help build your success. Treat them like gold, and they will do the same for you. One non-programmer that can inspire 10 "average" programmers to greatness is worth more than one great programmer who can't inspire their team to do more than meet their job requirements...

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...



People from a non-technical background think it's fast and easy to keep adding features to a project that's underway, then they don't understand why deadlines are missed and costs exceed initial estimates. As the scope creeps, you need to make sure that the people driving the project understand that more time/resources will be needed. A lot of developers hate scope creep, I think as long as it is managed it can be a good thing. It shows that the stake holders are interested in the project and they want to use it/are excited about it.

Corporations are cutting back on education for its employees which should mean that folks should be taking education into their own hands. Sadly, most people aren't continuing to grow...



In my humble opinion, this is stupidity at its finest and both parties are equally guilty. Just because your employer won't pay, doesn't mean you shouldn't spend your own time to grow. The job market demands the best and brightest and with so many corporations in trouble, you need to do whatever it takes to be on the top of the pile.

Likewise, if a corporation isn't investing in its people, how can they expect to remain competitive in the long haul? Of course, there is nothing wrong with short-term expense reductions in order to survive, but sadly much of the cost cutting exercises tend to be permanent.

Enterprise architecture can only be realized to the level of mediocrity if folks are allowed to be cube turtles for years at a time. Education varies greatly, but it's something you have to think about, not as a benefit (because it benefits the company for you to gain knowledge faster), but as something that you can use to further your career.

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 LogLogic, EnterpriseDB or Redmonk...

While I have had a Twitter account for awhile, it took me a long while to realize the value proposition that Twitter offers. While status updates are not conversations, they are the mode of the modern IT executive which I need to improve my interactions with.

The ability to communicate in sound bites is something that enterprise architects need to develop as a skill and Twitter is the mechanism that helps you build this capability. Gone are the days where IT executives had the mental capacity to pay attention. We are now in the era where anything more than two minutes is futile.

Anyway, I am located on Twitter here...

Do you recall your response to the news of your last reorganization? Were you excited and encouraged? Or were you dismayed, frustrated or even angry? What was the outcome of the reorganization? Were things notably better? Were they worse? Was there any change at all (other than to whom you reported)?

When it happens in IT, I am of the belief that it is symptomatic of two problems. Lack of strong technical leadership and substituting process for competence. When IT is not aligned with the business, not delivering value, not managing risk, resources and performance, then we have to do something. We have to change. The people organizing the reorg still seek genuine leadership but have no way of identifying upfront and simply keep iterating until it emerges.

Shops that have long CIO tenure such as Fedex tend to be better aligned because they have strong technical leadership and encourage IT people to make IT better vs focusing on using process as a substitute for competence.

Over the last three years I have blogged religiously sharing my thoughts, rants and screeds on a daily basis. I also stated that July 4th would be when I liberate myself from the blogosphere as the conversations are starting to disappear and be replaced by huxsters doing marketing, others doing perception management and causing churn.

It seems as if all the cool folks, the thought leaders, those who respect diversity of opinion have all moved to Twitter and so must I. I can be found on Twitter here. I hope to network with old friends as well as make some new ones.

Let's continue the conversation...

Nowadays, many developers make the choice to remain ignorant when it comes to certain practices...



Here are but some of the ways that developers continue to remain ignorant.

• Ignoring the latest community techniques and continue to develop software the way folks did ten years ago.
• Abusing the phrase unit testing by referring to actually doing the testing. They may choose a list such as do A then B then C and then the output should be D, if it's not then something is busted.
• Developers who don't unit test their code then get upset with QA when bugs are found that demonstrate the fact that they don't unit test.
• Having stupid debates on tabs vs spaces.
• Copying code from another application they've worked on containing the functionality they want to use but not changing the variable names.
• Not understanding the difference between "I need to get this done" and "I need to get this done here".
• The phrase "runs on my box".
• Believing that their code is so clear that they don't need comments.
• Rebooting is the first line of defense.
• Spelling mistakes
• Lack of focus on the customer and their needs
• Thinking that customers know what they want.
• Believing that catching (and possibly ignoring) an exception means preventing a bug.
• The web is stateless and the browser isn't part of your application.
• Ignorance of socially acceptable bathing habits.
• Inability to take pride in making mistakes.
• Ignorance of threading.
• Complacency with duplicate code.
• The lack of desire to continually improve.
• Failure to appreciate that software has no value in and of itself, but only adds value when it is used for something.
  

I have no clue but maybe some analysis of how thinks work in large enterprises is in order...



So, let's observe a conversation between an IT executive and others.

Enterprisey CIO: Even though I have no clue as to what business/IT alignment means, I need to craft a story around how to do this. I know that the business wants their Hello World application developed quickly but I must focus on perception management as my top priority. Hey enterprisey architect, can you handle?

Enterprisey Architect: Sure, got ya covered. I will first call up Gartner and get their Hello World magic quadrant where they rate all the vendors who provide Hello World functionality. I will then orchestrate a massive proof of concept where I invite in all the vendors to do a demo and hopefully a few of them will take me to lunch for the opportunity. Doing both of these things means that I don't have to think to hard on whether Hello World will actually solve a business problem.

Enterprisey CIO: Sadly, Gartner didn't have any advice on developing Hello World, maybe we can ask one of our favorite Indian outsourcing vendors.

CMMi Level 13 Process Weenie: We are more than glad to provide an estimate to develop your Hello World application. We have a team of senior developers with three weeks of IT experience that can aid your development.

Enterprisey CIO: Cool beans. So, what's next?

CmmI Level 13 Process Weenie: Well, we need to write comprehensive requirements and test plans for Hello World so that we deliver highest of quality.

Enterprisey CIO: Do you do Agile?

CMMI Level 13 Process Weenie: Sure, we do Agile, we do Waterfall. We do all of the latest buzzwords a client could ever hope to ask for. We never say no.

Enterprisey CIO: OK, so I want you to develop Hello World in six months. Could you do it in no less than one thousand lines of code?

CMMI Level 13 Process Weenie: That may introduce additional complexity.

Enterprisey CiO: Could you also make sure that the code actually compiles.

CMMI Level 13 Process Weenie: Yes, the functionality of writing code that compiles will be a small additional charge.

Agile In-House Developer: Hey, can I get a chance to develop this application. I know I can do it cheaper?

Enterprisey CIO: Absolutely not. The guys in India follow best practices. It says so on their website. You have a long way to go before you can reach their level of maturity.

Agile In-House Developer: Well, can I at least code review what they deliver?

Enterprisey CIO: Sure, I will also put it in your hands to ensure that proper knowledge transfer takes place. After all, the complexity of delivering Hello World and the knowledge behind it shouldn't reside in just one person's head.

Agile In-House Developer: Hey CIO, I found an open source version of Hello World that exactly aligns with our requirements.

Enterprisey CIO: You know we can't consider open source. After all, who is going to support it. I told you before that supporting Hello World requires lots of expertise and rigorous process that we simply don't have inhouse.

Agile In-House Developer: Well I will work with our outsourcing vendor to develop

CMMI Level 13 Process Weenie: We can do this one of two ways. I can annoy you to death with lots of idiotic questions or we can work together to propose alternatives to meet the dates. Don't underestimate the amount of silly questions I can ask. For
example, what code page should hello world use or should the H and W be upper-case or lower-case.

Agile In-House Developer: Why is this so freakin hard. My seven year old cat could write this in a day.

CMMI Level 13 Process Weenie: I warned you. I have to keep a team of a hundred people busy who are learning on your nickel. I can't simply get a single developer to write it in one day as I would get in trouble.

Enterprisey CIO: I see that my developer isn't working well with the offshore folks. Maybe its time to reduce scope.

CMMI Level 13 Process Weenie: I got a great idea. What if we were to deliver Hello in the first release and move World to version 2.0?

Enterprisey CIO: Great idea, I wish I thought of that. Now all I have to do is put together a slick Powerpoint for the business telling them that we have over 100 developers that will ensure top quality in delivering Hello World where they will
get Hello in the first release and everyone should be happy.

A style of management that is certain to be familiar to many...



Suddenly, out of nowhere, your management pulls up fast in an enormous car, rolls the window down, and sprays you (and possibly your whole team) with (again, figurative) bullets. You collapse on the ground, destroyed, all productivity stopped, your work required to change direction arbitrarily and heedlessly -- dictums from nowhere with no sense, completely arbitrary, that nevertheless require you to do everything totally differently.

You pick yourself up, somehow manage to stanch the bleeding, and get back up. After some time, you settle back down; the abrupt change in your plans works itself out, and you manage to recover from the catastrophe.

You're productive for another week or so, until, one evening, you're sitting on your (figurative) front porch, rocking lazily...

In my experience, "good enough" always includes hacks, sloppiness, bad commenting and spaghetti hell thus leads to lack of scalability, bugs, lagginess and prevents others from being able to build effectively on your work...



There are at least two aspects of quality that we have to take into account:

software quality: does the software meet the desired goals/requirements? do we deliver builds which have critical bugs? is it easy for end users to operate?
code quality: how hard is it to maintain the code? is it easy to implement new features?
If you're building a productized software, I think it is good to assume that it's never good enough in both aspects. Every little feature counts and if the users will not find what they need or the product is not stable enough, they will take a look at the competition. You also want to implement new features as quickly as possible, so that you have a competitive advantage in the market.

The situation gets interesting if you're building custom business software, where the end users and decision makers are usually not the same people, then the features/quality/money trade off becomes part of the negotiation process. What we usually do is we put "good enough" constraint on these three aspects: we have a set of requirements to meet, a quality to maintain and usually not enough time to keep both.

What is usually forgotten in this process is the second point: code quality or maintainability. We, programmers understand that sooner or latter crappy code will take its revenge and result in critical bugs or maintance costs. Decision makers don't. The problem is, the responsibility and risks are taken by you (your company, your division etc.) and you will be first to blame if something goes wrong.

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...

Distillation is a mental disorder...



Hasty generalization is a logical fallacy of faulty generalization by reaching an inductive generalization based on insufficient evidence. It commonly involves basing a broad conclusion upon the statistics of a survey of a small group that fails to sufficiently represent the whole population.

I have always held the belief that enterprise architecture needs to address the human aspects of technology for strategic competitive advantage...



Of course this means that you have to understand not just what is busted regarding IT systems, but the human elements as well. So, below are the worst practices of modern IT management:

• You don't fix bad management and instead classify it as a problem with perception management
• When something isn't working, do more of it.
• When something works, but makes only a small difference, do more of it because that's bound to make a big difference.

Collective crimes incriminate no-one...

Are you or others you know making decisions or assigning tasks in a manner that mitigates anything being blamed on anyone? This can be encouraged by organizational practices that look for someone to blame when something goes wrong, rather than looking for things to change to prevent the error in future.

Blame avoidance reaches its peak when its employees also spend inordinate amounts of time on perception management. This causes enterprises to look good on the surface but to rot away internally. Think Enron.

Have you noticed that cultures that center on blame avoidance aren't very innovative? Blame avoiders typically focus on the following, in decreasing order of importance:

• how they appear to others
• how their department appears to others
• how their organization appears to others

Innovators and engineers typically focus on the following in decreasing order of importance:

• making things
• making things that work
• making things that are useful

So, is blame avoidance a good thing or a bad thing? You should have this conversation within your own ecosystem and see what answer emerges...

When individual initiative is preferred rather than top-down centralized control, there are few clearly-marked lines of authority...



It would seem on the surface that this is a very good arrangement, very empowering and all, and it's true - it does create a nice, collegiate atmosphere - but I think there is a dark side.

The problem comes when IT as a team, is eventually expected to provide benefit to the company's bottom line. At this point in its lifecycle, significant effort is spent looking inward to architecture, methodology and so on. This is all well and good (it helps pay my salary, after all), but it is not clear what brings this process to an end. When you set your own scope and in essence become your own customer, accountability is lost. Without accountability to the business, the process could be never-ending. So at the end of the day, whose "fault" is it?

One could say that that IT leadership at large should have more personal discipline and prevent such projects from ballooning that way. But this is not just an individual phenomenon. This is a "game" that involves several players, and no one individual is to blame.

Top management must recognize that the behavior of a team is not the same as that of an individual. Just because you have a group of highly motivated, bright, talented people does not mean that you have a well-functioning, productive team. The team must be trained with theory and practice to achieve the results they are expected to achieve.

If an owner of say, a horse, just lets the horse graze all day and hang around the farm, and does not train it, he should not be surprised if that horse is useless when he really wants to ride it somewhere or do something else useful with it. A team is more like that horse - it has to be cared for, trained, disciplined, and used in the way it is intended. Neglect just leads to problems, benign or not...

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...