Wednesday, April 30, 2008
Does your head want to explode whenever you attend a meeting?
So, why do folks in large enterprises have so many meetings? Does the enterprise have a communication problem or is the need to communicate so much a problem itself. Is it due to the curse of the matrixed organization? How come IT executives don't ever think about reducing the amount of communication needed whenever they reorg?
How many meetings do you attend where the project managers sole purpose for calling it was for something that could have been communicated in a quick email? Do you need to see me face-to-face in order to tell how I feel on certain topics? I trust I am not alone it these experiences and would like to know how others keep the interest of those attending and how they help project managers stay focused.
Please note that I am talking about more than just having an agenda. When I was a consultant, I remembered how difficult it was to get all those PMP certified project managers to take notes during a meeting and to produce minutes. If meeting minutes aren't produced, does that mean that I have to de-optimize my daily activities on the sole chance that something profound may occur?
I can say that I've also seen great success in asking the question before a recurring meeting - "Does anyone have anything new to present or should we cancel today's meeting?" After all - why meet if there's nothing new to discuss. On a related note, a meeting is not a good place to accomplish tasks that should be handled outside the meeting, but I suspect that PMP doesn't teach this simple truth. One of my favorite phrases for meetings is - "let's take that off-line and get back with the group." Asking all attendees of a meeting to be present for a discussion that only deals with a small portion of the attendees is a waste of time for those who aren't directly involved in the decision making process.
If you see that meetings tend to start late, it's often a good idea to either reschedule so that its possible for attendees to be on-time or start enforcing the start time of the meeting and don't wait for late-comers. If your company allows it, you may also want to consider a wiki to post the notes to and provide a place for others to comment between meetings. This is especially true for roll-up meetings that include subcommittees where they hold their own meetings.
Part of having a successful meeting requires enlisting individuals with passion around a topic. If you are a non-technical project manager who is attempting to lead a highly technical discussion, then you certainly need to either step up or tap out. Focus on keeping meetings interactive and interesting. Liven it up every once in a while too with something quirky or fun. You can also shorten a meeting without prior notice once in a while - for instance letting the people know at the beginning that the normally 1 hr meeting will be cut to 1/2 hour today - what are the top 2-3 priorities to be covered? Then let them go utilize that 1/2 hour of saved time!
Noodle bringing Chocolate to meetings as a form of bribery. Prefer dark chocolate as it keeps people alert and tends to get the creative juices flowing. A worst practice is to make meetings mandatory. This is the best indicator as to the value and usefulness of the meeting. If no one shows up, it's their way of telling you that the meeting is of no value to them. If they show up voluntarily, it is a good indicator that they expect your meeting to be useful. If they show up, let them leave whenever they want, once everyone is gone (even if it's 15 minutes into the meeting) the meeting is officially over...
Tuesday, April 29, 2008
Enterprise Architecture and Taking Credit
Harry Truman once said It is amazing what you can accomplish if you do not care who gets the credit. The people who count will know who did it, so don't worry about the credit and instead focus on value creation. It is often the case that though you tell people what you have done and you have pride in your accomplishments, that other more powerful and more strategically placed people may receive the credit anyway. Over time, this becomes a trap in that you may worry that you may not have gotten your dues.
Don't worry about the credit, even if your claims are just and true. You have accomplished your mission and should be savagely focused on improving your skills so that you can do even more. Don't fall into the trap as the workplace usually isn't fair nor objective. If you are truly worried about credit, then try a credit monitoring service such as Experian or Choicepoint that notifies you anytime your credit report changes.
Besides, if you are one of those folks who believe that perception is reality, then you may also conclude that those most worried about getting credit typically are those whose contributions are least worthy of it...
Monday, April 28, 2008
One cannot "fight" for peace...
Do you know any project managers who live, breathe and bathe in the waterfall?
The PMP indoctrinated model for software development is broken down into sequential steps: Analysis, Design, Coding and Testing. There are a variety of reasons why enterprises still aren't agile. It could be ignorance, fear, pride or even fraud. Fraud is an interesting dimension not previously discussed by others in that many become project managers in large enterprises without having ever actually developed software themselves. They pretend to understand but in all reality have no clue. Ignoring this truth for a moment, waterfall is an acceptable way of failing.
The first signal that an enterprise is practicing waterfall even if they believe they are agile is when folks say they are too busy. I wonder if others have detected a loose correlation between a project's health and the availability of project members to help others? For the record, I am not suggest that your project team be interrupted by a stream of questions that will ruin any remaining productivity, especially when the person asking the question could have simply read the fine manual.
If a project member can't reply to others within two hours, this is a prediction that something is wrong. This may be a hint that they are using process as a substitute for competence and the facade of actually knowing is starting to crumble. It could be that assigning a person five tasks where they are supposed to spend 50% of their time on each is simply stupid, or it could be that they are simply focusing on something more important than their own project.
In the past I have talked about big design upfront but skipped over an even bigger problem known as drive by analysis. Remember, the more you pump a customer up with a formal analysis phase, then immediately linearly followed by months of invisible tinkering, the more elated they will be to see their dream implemented after the final hooray of big bang testing.
Every project, no matter how big or small, begins with analyzing someone's nebulous idea of what the customer wants and then giving The Customer what they will accept. There are no exceptions to this rule. One must negotiate this realm of the possible even if you are your own customer.Therefore, on any project everybody is a customer" for someone else's product. So, in your enterprise, do you still have it twisted as to who the customer is?
Sunday, April 27, 2008
What does it mean to be LDAP compliant?
His phrase: in order to do ActiveSync on the ADAM interface, we need access to the LDAP transaction log, which is available LDAP directory, but not through ADAM (which uses AD via ASDI) didn't mention where the notion of a changelog should also be in the RFC? From what I can tell, Microsoft did the right thing but other applications that are so-called LDAP compliant also expect the changelog to exist. Documentum and other enterprise applications have also made this mistake.
Ignoring standards for a moment, is the notion of a changelog a sign of fugly application design? If you are synching to LDAP, then understanding the deltas could be considered a good thing but isn't the better answer to bind directly at runtime?
I am curious to learn how/if Oracle Virtual Directory provides an answer...
Things you can learn from George Bush...
1. Lying is O.K.
2. Cheating is O.K.
3. Torture is O.K.
4. Taking people’s rights is O.K.
5. Neglecting the poor is O.K.
6. Being a religious hypocrite is O.K.
7. Killing is O.K.
8. Incompetence is O.K.
9. Cronyism is O.K.
Saturday, April 26, 2008
Are you a CISSP?
Why employees of Accenture, Wipro and Bearingpoint suck...
I have noticed an interesting behavior of employees at these firms that I figured I would provide commentary on in hopes that it would change. Have you ever been invited to a meeting via an Outlook calendar invite where you only think about it in context of your own attendance but not whether others could also benefit?
Within the IT ecosystem, there are a variety of folks who spend lots of their own free time putting together wonderful user group meetings, sending out invites and yet folks never seem to think for a second how their peers could benefit even if they couldn't attend. I know that you have been indoctrinated to not actually read most emails and are simply scanning for keywords you feel are relevant to you, but if knowledge management were to actually materialize, it would require humans to think about making others better and not just a singular focus on ones own existence.
Interestingly enough, I attend lots of user group meetings for personal development purposes and have noticed a pattern that employees of large enterprises tend to participate deeply while those who are employed by technology companies such as Sun, EMC and others tend to be missing in action with the exception if they are there to present or to sell something.
Even if you run across the straggler, you will almost never see anyone from Accenture, Wipro, Bearingpoint, Infosys, Satyam or Cognizant in attendance as the traveling crowd for whatever reason tends to not be aware of technology events in the areas in which they travel. One observation is that folks who run user group meetings could send invites to these folks but that would require a way to know that they are in the area which usually isn't public. So, what is the alternative?
If you happen to be employed by any of the firms mentioned so far, ask yourself what would it take for you to track down a few colleagues who are currently deployed in the CT/MA area and ask them if they will be attending the next meeting of OWASP? Its OK every once in awhile to consider others...
Friday, April 25, 2008
Oracle Authentication Services for Operating Systems
First, if you are running Solaris, this you can setup NIS domains to aid in this problem. However, if you are left out in the wilderness because you are using Redhat Linux and haven't been pestering them to provide equivalent functionality, then your choices are more limited. There are however some sound alternatives that are less expensive than what Mark is proposing.
Consider that if you are a shop running Active Directory, Microsoft provides Active Directory Services for Unix where by you can have Unix servers and daemons participate as if they are native to the Windows domain. This simplifies administration significantly, cheap to rollout and even cheaper over the lifetime. There are of course some features missing, which Microsoft will be addressing in upcoming releases.
You can also consider third party software such as Vintela and Centrify which also provide deeper Unix/Linux integration to Active Directory. Anyway, I humbly predict that the open source community will realize that this type of integration should be in the box and not something add-on and therefore will address within the next six months.
As for Oracle, they shouldn't worry as most architects in large enterprises are asleep at the helm. Provide them with good Powerpoint and some trinkets, and this product will do well...
Open Web Application Security Project - Hartford
If you happen to live/work in New York City, Boston or anywhere in Connecticut, you may want to check out the April 30th meeting for the Hartford CT Chapter as it will feature Jack Danahy, CTO of Ounce Labs and Anton Chuvakin of LogLogic.
The event is free to attend and we even feed you. No RSVP is required...
Thursday, April 24, 2008
Hypocritical perspectives on open source...
Figured that this is a great opportunity to share some of my own personal thoughts regarding who should contribute to open source and more important who shouldn't. Consider the simple fact that most open source is not targeted at a particular industry vertical where many of my enterprisey friends spend most of their time learning their craft. The skills that it takes to be a successful developer to write a claims system is fundamentally different than being a successful developer who writes an open source portal or operating system. If you were to take Linus Torvalds and asked him to write a policy administration system, he could do it, but this is not within his zone of comfort. Likewise, I could find some really good developers in large enterprises who work on systems such as policy administration, but they may not have what it takes to write an OS kernel.
So, the first consideration regarding contribution is if you have the right skills which are deeper than just knowing a language. Of course this means that you have already abandoned the thought process that all Java developers are equal and haven't drinken the new FTE capacity planning kool-aid. A second consideration is that there are enough developers on the planet that can write code and the open source community doesn't need much more. What open source sorely needs is good documentation and therefore if an employee of an enterprise contributes to open source, they should not focus on source code but should focus on documentation. This could come in the form of writing books, magazine articles and sharing knowledge about a product in blogs and wikis. In many ways, the conversation is more important than the source code.
Taking this one step further, enterprises need to stop thinking about NDAs and to start thinking about ways to make their requirements more open. For example, if I am struggling with a problem space of making an ECM platform implement XACML and I provide several use cases, why should I only send it to the incumbent enterprise vendor? One take says that when enterprises articulate requirements, software vendors listen, NOT REALLY! What software vendors do listen to is how they compare to their competititors of which open source is one of them. Do you think that Documentum would allow for really cool features to exist in Nuxeo, Alfresco and other wonderful open source ECM platforms without them also having it? Sometimes the fastest path is to share requirements with your vendors competitors.
From a personal perspective, folks know that I have in the past contributed code to open source projects. I remember my first contribution in the security space where the code was functional and even secure, yet I remember receiving sarcastic comments via email from others saying that I code like I am an Enterprise Architect. Reality says, that the characteristics of what I consider good code as part of my day job, simply isn't good code by outside standards. Enterprises who don't appreciate the subtle difference can embarass themselves.
Code where their is collective ownership is most worthy of contribution. However, if your enterprise has outsourced software development to India where the vast majority of IT professionals are junior and lots of folks have stepped on it, then it may not make a good contribution candidate no matter how functional it may be.
In terms of contributing code under your employers name, I think I have an unpopular but accurate perspective. Reality says, that in order to write worthy code, it requires significant desk time. In today's meeting oriented culture, who has the time to have a continuous cohesive thought while at work. It has been eons since I have been able to keep a thought going uninterrupted for more than one hour while at work. Attempting to write worthy code in this scenario is futile. Reality states that the only time you can think cohesively is at home and therefore you are not on employer time...
Wednesday, April 23, 2008
Encouraging IT employees to quit En Masse
Have you ever considered that a mass exodus from your enterprise is beneficial to the IT profession as a whole? Usually folks quit because they have either lost faith in the organization for one reason or another or that the job market is very hot for their particular skills. While this may be bad for the losing company, it can be a huge boost for the industry at large as expertise becomes more spread out.
Would Indian outsourcing become stronger if the truly top talent within Wipro, Infosys, Satyam and Cognizant were to stop moving amongst each other but instead were to diversify into large enterprises? What would happen if there were a mass exodus of partners from Accenture, Bearingpoint and McKinsey? Would it result in more diversity, creativity and innovative ideas to emerge?
Enterprises should always put a positive spin on folks leaving en masse even when they don't deserve credit. The marketing pitch says that if your enterprise has lots of folks being stolen, then you may be the career path for those who also want to get stolen later but don't have the right credentials now and you can milk them for whatever it is worth. Besides, usually when this happens, IT executives tend to conclude that they won't fix the culture and therefore shim it by paying more...
Tuesday, April 22, 2008
Why Project Managers should NOT lead projects...
I bet if you were to ask the opinion of every business analyst, developer and architect, they would be in universal agreement that project management in large enterprises is headed in the wrong direction. Yes, we have our bodies of knowledge, our cliche best practices and most importantly our savage passion for repeatable process, but with all of this, we still forget the fundamentals.
Hybridism is a mental disorder that has permeated the thinking in large enterprises where architects and project managers are supposed to be peer roles in projects yet we haven't yet figured out that IT projects are best led by architects and not project managers.
We should never all dual leadership structures in project teams. Don't buy into extreme egalitarian nonsense. Someone must be appointed and supported to lead the charge, set the tone and manage the risk and deliverables to completion. If you happen to have a project manager with a technology background then you can compromise by putting this person in charge, otherwise architects should lead the assault.
Enterprises should always build project structure that supports the mitigation of risks that pose the greatest threat to the project. Nowadays, technical integration between a plethora of systems tends to be a recurring theme where architects are best positioned to mitigate risk.
If the greatest risk is software quality, engineering disciplines should be preeminent on the project, whereas if visual appeal and speed are most important, it may make some sense to put someone creative in charge.
Most of all, always heed the need for deliberate thought and design around team structure, leadership and project roles...
Monday, April 21, 2008
Why Enterprise Security still continues to suck...
- First time for me to RSA, I generally go to more geek-to-geek conferences like OWASP.
- There were soooo many vendors yet most of the products in the massive trade show floor would have as much an impact on the security in your system as say plumbing fixtures.
- For years the excuse that security people gave for their field's propensity to lameness is that "no one invests a nickel in security." However, that ain't the case any more and yet most of the products teh suck. This doesn't happen in other areas of computing - databases are vastly better than a decade ago, app servers same, OS same, go right down the list. What gives in security? Where is the innovation?
- I would attribute to a lack of accountability. In programming your stuff better compile or you don't go live, you don't get your bonus, people get whacked and so on. In security there is no bar to clear generally. People play cops and robbers off in some corner of the enterprise, right draconian policies that are ignored, and life goes on.
- The other thing that struck me was that everyone was selling their butts off, and I realized I have no budget to buy, so I might as well have something to sell. What about training?
Sunday, April 20, 2008
Why Enterprise Architects need to support the role of technical lead...
It is too much to ask for an architect to be conversant with the details of programming (e.g. give estimates on project design and programming costs). Likewise, one should not ask the "technical lead" about the implications of infrastructure decisions.
Many project managers ask the right questions only that they point them to the wrong demographic. The funny thing about being an architect is that we love our analogies that refer to the building trade yet we so frequently skew the meanings to fit the moment while not ackwoledging why we mostly suck.
If you could across a high-ranking architect with a blank look when discussing low-level issues, then he/she is not an architect. They are more than likely business analysts who went off course. He will probably wax lyrical on all things high-level and "important". He will produce lovely object hierarchies without a clue to implementation. He will use buzzwords such as best practices and champion heavyweight processes such as CMM while being good at playing golf. His background may also been employed in the past by a very large international insultancy.
The role of the technical lead is the solution to the miseducation of the architect demographic. I think the problem is that typically there are not enough "technical lead"s to address the communication gap between the architect and the programmers. A good "technical lead" should be able to understand the issues of concern to architects, and a good architect should be able to understand the concerns of development and maintenance programmers. A willingness to align and communicate should be the trait of both types of people...
Saturday, April 19, 2008
Collaboration and Enterprise Architecture
Collaboration in large enterprises really is permission to create repitition while piling on aesthetics and maintainability. It is virtually impossible to communicate in a manner in which all parties understand at the same time and therefore repitition is required...
Friday, April 18, 2008
Enterprise Architecture and Orders of Ignorance...
Thursday, April 17, 2008
Don't Fight the Process
Ignore agility as the vast majority of folks in your enterprise will become paralyzed by the slightest bit of uncertainty. Additionally, they will be unwilling to figure out for themselves what will work. Enterprises in 2008 lack both the ability and the desire to expiriment. IT no longer has geeks as the corridors are filled with folks who need to be told the right way to do everything before they are willing to take on the task.
It is important to understand that there are people involved who are unwilling or unable to act without heavyweight process and if you change it, you will destroy their purpose in life. While a more agile process would be better for the business at large, it is not necessarily better for everyone....
Wednesday, April 16, 2008
Links for 2008-04-16
Analyst firms are in trouble and now is the time to redouble their efforts by providing value to both sides of the house. Those who pay for research as well as those who consume research with a focus towards the latter.
Good to see that both OpenID and CardSpace are staying competitive. Of course I predict that CardSpace will beat OpenID in the enterprise...
We need more women in IT. This should happen by adopting not just men who convert but also those who are naturally born that way
I wonder if Alex Fletcher, James Governor, Raven Zachary or others know the answer to this question?
Here is one post that Oracle, Sun and HP will exercise their right to remain silent on
They should instead consider attending their local Delhi chapter of OWASP so they can learn security beyond the surface.
Wouldn't it be interesting if you could not only register a SQL table, but also a directory service exposed via LDAP?
I wonder if OWASP needs to create the Secure Project Management Project?
Good to see that Nishant Kaushik agrees with Pamela Dingle that software vendors need to figure out how to externalize authorization. The harder part of the question is how can Oracle help other vendors such as Documentum understand how to do it correctly
Dave Parsons provides good insight into incorporating security into 2.0 thinking. I am surprised he didn't mention that individuals should consider attending local OWASP Chapter meetings?
Process as a substitute for competence
Why can't so called champions of Agile simply admit that they are doing unmodified 1977 style waterfall? You will typically find that most enterprises who outsource work to India where the developers are largely out of contact with architects results in a staggering amount of process.
On one recent project, a developer I knew wrote a custom authentication scheme for Siteminder doing pair programming which took only fourty five minutes. Management of course insisted on a 5-page requirements definition document, two management reviews of that document, a functional specification with four contributors, a peer review and a management review of that document, a detailed design document, a management review and sign-off of that document, and a test plan before development could begin on the code.
The code in question? He started with a sample application and modified six lines lines of Java.
If you believe that the need for process is strong without questioning in the same breadth as to whether it needs to be heavy then you really should smack yourself silly every time you use the word Agile.
I humbly predict that the socialization type architects will drive the enterprise into the ground. The ever increasing amount of meetings is simply a so-called agile way of documenting less but otherwise still wasting time where neither no one actually understands nor does work get done any faster. Recently, I was asked whether I felt comfortable with a particular project moving forward. I could have used my influence to simply state that I don't feel comfortable while also avoid articulating any rational reason for not and could have gotten away with it.
Anyway, Why on earth is so much process present? Why does it take three documents and six meetings to write six lines of Java? There are twice as many pages of documentation as lines of code! Well, having worked with the people involved on these documents, plus the development, and the testing, not just on this project but several others, I think I've figured out the purpose: process is being used as a substitute for competence.
The funny thing is that I too am losing my sense of humor and are starting to become borgified and believe that CMMi is the perfect way to use process as a substitute for competence. With enough steps, documents, design reviews, and test plans, I think that the proverbial 1,000 monkeys with typewriters really could produce a functional IT system. The incredible amount of mutual reinforcement breaks the task down into such minute pieces that each piece is comprehensible and completable by anyone with even the slightest modicum of coding or testing ability.
The added advantage is that no one is required to think let alone understand. It even helps project managers to a pretty good degree of accuracy how long each minute task will take, and can thus do a pretty good job coming up with a (obscenely long) timeline for a project in any stage of development.
If the business only knew that IT didn't actually know IT...
Tuesday, April 15, 2008
Enterprise Architecture, Whiteboards and Bad Project Management
For those who entered the IT profession in the 80's and 90's, you would remember the days where we would cover the walls with ER diagrams and UML. Those where the days where architects worked on architecture. When was the last time you were in a large enterprise and saw models on whiteboards?
I bet if you were to walk your own hallways, you may notice that the whiteboards of architects are now covered with timelines and other notations not traditionally associated with architecture but strongly correlated to project management. Is it that architects are no longer doing architecture but project management?
If architects are really technical project managers then what are all the non-technical project managers up to? If architects are doing multiple roles, then why can't we rationalize away having two different forms of project managers. If you are wondering why IT is so expensive, maybe you should look at this relationship...
Monday, April 14, 2008
Architects, who needs them...
Recently, I read the most wonderful posting on why the role of architect needs to disappear. Reality says that time proven theories such as Deming proved that enterprises need to delegate a lot lower than what is currently happening. Reality says that architects, if anything with their governance models are headed in the exact opposite direction. While there has been short term lift from these approaches, the long term consequences aren't well understood.
Of course, you have to acknowledge that there are different types of architects within large enterprises. First, there are architects who are assigned to projects. These folks are the antithesis to agility at one level but also being squeezed by those even less agile at the top. Part of the rationale for having the title of architect has less to do with role and more to do with job grade. How do HR weenies delineate two people who are both senior?
If you were to study cause and effect, the role of architect also means the one who governs code that is developed offshore. Since Indian outsourcing as it is commonly practiced means that even architects don't necessarily talk to programmers (I can't call anyone in India a developer) someone else has to have local authority to say that things have gone haywire. This is the new meaning of architect in a non-agile world.
The second type of architect is best known as an Enterprise Architect which is less about projects and the building trade analogy and more about managing a portfolio. The investment analogy works better than the building trades here. Architects here figure out strategies around arbitrage, when to buy, when to sell and so on. For this role, the is less about agility in the sense of agile software development and more about governance in terms of a behavior model.
So, my conclusion says that we need less project-oriented architects and more enterprise-oriented architects. Of course, others have their own thoughts that I would love to hear and it would be great if you could respond via trackback...
Saturday, April 12, 2008
Why Microsoft should be at the center of the identity universe...
Many enterprises have hundreds, if not thousands of Solaris and/or Linux servers yet administrators are still forced to provision users to each and every box. IT departments need these systems to "plug and play" so they don't have to spend their budget acting as a systems integrator or having to manually (and expensively) administer an ever-growing number of systems individually. Wouldn't it be great if the folks from Sun and Redhat put into their respective operating systems a way that they could participate in an Active Directory domain.
The benefits are huge if Solaris and Linux became Active Directory clients. Organizations can then secure those systems using the same authentication, access control and Group Policy services currently deployed for their Windows systems. Linux and Unix are the biggest perpetrators of propagating redundant identity stores.
Likewise, think about the productivity gains if Linux and Solaris could also coordinate with Active Directory Group Policy Objects so that access control is more standardized. Sun of course is championing their own LDAP which at some level makes sense but at another level is encouraging duplication where the focus should be on integrating and leveraging what you already have.
The odds are pretty good that there are more orphaned accounts in Solaris and Unix in most shops than there are in Active Directory. The ability to immediately and globally turn off accounts of departing employees is significant. Furthermore, the ability to identify dormant accounts centrally using AD is huge.
The real question that needs an answer is how can Microsoft help Oracle, EMC, Sun and others understand how to do the right thing. The conversation needs to move away from IDM Provisioning and towards directory consolidation...
Friday, April 11, 2008
Does EMC contribute to open source?
I wonder if anyone from Documentum or the RSA side of the house can comment on contributions or is the story simply limited to using and not giving back?
Thursday, April 10, 2008
Are software vendors aware that developing software in India causes customer dissatisfaction?
Imagine a scenario where I am developing an enterprise application where I need to combine a BPM engine such as Pega with an ECM system such as Documentum in order to handle a complex business process. Of course, a wise and humble Chief Security Architect advises me that I should figure out how to reconsile disparate authorization models between these two platforms. Ideally, he believes that these two vendors should work together to come up with the common solution but of course will fall back to a position of writing this type of integration in-house in order to be truly secure as many software vendors aren't doing the right things when it comes to security.
I decide to attend an industry conference such as AIIM, RSA or others in hopes of running across others that may have ran into the same challenge as I. I find hundreds of folks who have the same problem and on the surface all of our problems sound different but in reality we are all struggling with the same problem. In past conferences, I used to get the opportunity to not only network with other attendees and the occasional speaker or two, but actually got to have face-to-face interactions with the folks who wrote the product. We would agree to exchange business cards and I had another channel that I could leverage when I struggled with level three support or even just needed someone to exchange ideas with.
Long gone are the days of a customer being able to interact with a developer. It has been replaced with non-technical sales executives who function as condoms to protect us from them. Sales executives fear the disease of the customer being able to hear unadulterated words that haven't been finely sanitized by media relations where only a handful can actually talk to us.
I remember the days where I would run across interesting folks in airports, at conferences and even on vacation but those days are long gone. I guess if I happen to be strolling down a street in Bangalore, I might be able to bring back the experiences of the past that worked so well. Today, I am now forced to deliver less because we get less technical support than we did in the past.
Do software vendors understand the power of community? The enterprise has never said that we didn't want to pay for interactions. In fact, every signal says that we are willing to pay even more for such cherised conversations. Do sales people realize that they need to enable conversations between customers and those who write software? It is not really about efficiency and management as much as it should be about delighting us customers.
I remember a visit to the Microsoft campus in the 90s where I had the opportunity to interact with the Exchange Product Managers. I got the opportunity to sit at one of their desks, eat lots of pizza, check out how they test software and even took pictures (against Microsoft policy) of them having five computers on their desk that I proudly showed to others. Is it too much to ask sales folks to help me have a meaningful experience?
When you outsource to India, you aren't really saving money as us customers don't just appreciate interaction, in many cases we require it. The open source movement in some ways is the solution to our burning desires where we can actually have a conversation. Imagine if Oracle arranged for a way for the guys that actually write the Oracle DB kernel to come and talk to us or Microsoft were to send Kim Cameron. Do you think many folks would appreciate this? I bet you know already we would tell others and do something more profound than your own marketing department could ever hope to pull off.
Software vendors, you need to seriously reconsider isolating software developers in your own shops as well. I know that their own personal satisfaction would also improve if they could have conversations with us. Everyone takes pride in their work and nothing is more personally motivating than understanding how someone else uses the fruits of one's labor...
Wednesday, April 09, 2008
How many Project Managers does your IT shop have?
Folks in human resources do a wonderful job of tracking the salaries for specific positions within a geographic location or industry vertical. Have you noticed though that while they are babbling about work/life balance, none of them ever track the ratios elsewhere of project managers to developers which is the leading cause for lack of balance?
Wouldn't it be curious if we all stopped focusing on worst practices encouraged by CMMi and instead indexed ourselves against top IT shops such as Microsoft? Would it be interesting to understand the ratio of project managers to developers in Microsoft vs our own shops? I think we all know what the numbers would show but some speculation is in order as to why.
Some would argue that the differences are in the business model. I would argue that the difference is more in the folks who run the business. For example, you wouldn't need to explain simple IT concepts to Bill Gates but may need to in your own shop. Within an accounting firm, the partner usually worked themselves up through the ranks and therefore junior accountants aren't spending time explaining why one needs to do double entry.
Would work/life balance come into harmony if there were minimum criteria in order to be an IT executive? It has to be more than simply managing
Developers are the step-child of most IT shops nowadays and have to deal with incompetent project managers, idiots that come up with colorful but otherwise incomplete architectures and on top of that are being increasingly coerced into methodologies that are crap while having to fix up code written by freshers in second-class countries such as India. No wonder college kids don't want to become computer science majors anymore.
Other than a conversation on PMBOK or other methodology approaches, what guidance would you give to the project managers you work with?
Tuesday, April 08, 2008
Enterprise Architecture and Fire Drills
A Fire Drill is a recurring scenario in many software development organizations. A project is initiated, but the staff delays design and development activities for several months while various technopolitical issues are resolved at a management level. Enterprise Architects then scramble to create Powerpoint while the problem at hand that actually caused the politics is in the rapid creation of working software.
At some level, enterprise architects create noise in order to avoid duplication of the portfolio. What ends up happening is that we let the components of our ecosystem that we like devolve by distracting others with politics such that they don't have time to do it right. It was once said by a wise developer Wait until management is desperate and they will accept anything you give them. When will we get smart enough to stop attempting to manage politics and start managing our portfolio?
Management prevents the development staff from making progress either by telling them to wait or by giving uncertain and conflicting directions. Perhaps most destructive are the externally generated changes in project direction that lead to rework and inhibit progress.
Because the entire project is pressed for time, compromises are willingly made in software quality and testing. In a perverse way, the emergency situation makes the job easier for some software developers as management will accept almost any software (or documentation) product with few questions if it is behind schedule. However, conscientious developers who deliver products before their deadlines are often compelled by management to rework their solutions.
Enterprise architects should be a condom of sorts to protect developers from the disease known as IT executive politics where they can focus on long term continual progress towards software delivery. Likewise, Enterprise Architects themselves also need to remind others that as much as 80% of all code in applications really isn't application-specific and therefore it is OK to proceed in that you won't really need to refactor as much as you think.
At some level, the mindset of rework comes because us enterprise architects haven't figured out how to get project managers to think in ways other than waterfall. Maybe it is because us enterprise architects haven't figured out how to sell Agile...
Monday, April 07, 2008
Enterprise Scenarios for CardSpace
Figured I would dissect his most thoughtful posting:
- Hey! CardSpace is not just a consumer technology. If you think it is, you're missing the point. It is a bit frustrating to hear even some of my Microsoft colleagues refer to CardSpace as though it belongs on the shelf somewhere between Zune and Halo3.
- To see why, take a look at the scenario I bumped into recently in the insurance industry. As anyone who has purchased insurance knows, many products are sold and sometimes managed by independent insurance agents. For these products, the industry is not simply a collection of large, competing carriers; it's an ecosystem of inter-dependent organizations.
- It's often highly impractical to manage the identities of these non-employees as though they were internal members of your own organization. Yet at the same time, providing direct access to internal resources or applications can really streamline core business processes-if this access is secure.
- In short, organizations must demonstrate their willingness to consume identity tokens from external identity providers. But they will hardly be willing to invest in the technology to consume tokens if there are no providers. The chicken and egg problem rears its ugly head once again.
Another thought says that these types of relationships won't happen quickly due to regulatory considerations. Imagine a regulated industry vertical that is on the radar of the likes of Elliot Spitzer. Do you know how difficult it would be for multiple carriers to talk with each other regarding technology without some lawyer somewhere getting it twisted and thinking about collusion?
One potential answer to collusion is that software vendors such as Microsoft, Oracle, Ping Identity, Sun and others could stop sending their order taking sales folks and start figuring out what role they need to play in terms of community formation. I would love to see Patrick Harding share his thoughts on this topic as he has the perfect background in order to make this happen.
The funny thing about Microsoft is that they should at some level consider their own use cases. For example, I know that Microsoft outsources its benefits administration, wouldn't CardSpace make it more secure for their own employees? I would be curious to learn the actual implementation details of how this works today within Microsoft. I wonder if they are leveraging ADFS, OpenID or some other technology?