Enterprise Architecture: From Incite comes Insight...

As anyone who attends a lot of meetings knows, there are some that are great and motivating and then there or those that are not. Many times I have walked out of meeting with out a clue as to what the purpose of the meeting was about and no real resolutions emerged...



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

During annual review time, my boss gave me feedback that I don't take enough credit. I figured I would start a movement to convince other architects that taking credit isn't always a good thing...



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

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?

I was reading Sean ONeill's blog on ADAM and LDAP compliance when I noticed he skipped over something I have always been curious about...



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

The below picture reads...

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.

Are you participating in your OWASP Chapter? Did you know that you can get continuing education credit by attending? Did you know that chapter meetings are free to attend?

Accenture, Wipro and Bearingpoint are three consulting firms that are savage in the pursuit of knowledge management yet have missed out on one of the biggest opportunities to harness knowledge...



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

Mark Wilcox discusses the first release of software that simplifies the authentication and account management process of Unix/Linux servers. On one level, this feels like a good story, but on another it feels like a long-term trap.



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

The Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks.

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

Awhile back, I asked if EMC employees are embarrassed that their employer uses but doesn't contribute to open source. Several bloggers inquired via comments as to whether my own employer does implying a level of being hypocritical...



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

Many folks gossip in the hallways of large enterprises whenever a demographic quits en masse. I figured I would outline positive perspectives on this activity...



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

In the 90's, the role that led a project was known as project leader, however the title has been rightsized as the vast majority of the folks in this role don't have a clue about leading but could possibly be successful at managing if they stick to making checklists...



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

Industry Guru Gunnar Peterson provides a debrief on the RSA Conference that is a must read...

First time for me to RSA, I generally go to more geek-to-geek conferences like OWASP.

I am in the same boat as Gunnar. Why would I want to consume my budget just to learn about security products when I could instead attend OWASP events such as the OWASP AppSec 2008 in New York City where real security discussions occur. RSA is only of interest to those enterprise architects who practice productecture and need to be spoonfed the latest elevator pitch because they aren't capable of comprehending anything else. Folks that attend these conferences are dangerous to the enterprise.

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.

I bet there were lots of industry analysts and the media swarming though. It is guaranteed that there will be lots of press from industry analysts coming out the event but no real innovation.

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 have to disagree with Gunnar in that I still believe it is true that no one invests in security. The problem at some level is that folks are investing in security products and not in making existing products secure. For example, all the security vendors came out of the woodwork to demonstrate XACML interoperability, yet none of the vendors demonstrated how to embed XACML into their ECM, BPM, ESB, etc solutions. It is guaranteed that the folks at RSA are working on XACML products yet they aren't working with their own inhouse developers to put XACML support into Documentum.

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.

Gunnar is 100% accurate here as their is no body of knowledge that one even needs to know before labelling themselves as security architects. The funniest of observations is that there are many security professionals who on one hand acknowledge that security should be implemented in layers and likewise that you need to protect both at the infrastructure level and the application level yet on the other hand have never written one scintilla of code in their lifetime. Maybe we have to work harder to convince these folks that they aren't doing security but are only doing network hygeine.

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?

I normally don't provide public endorsements of anything or anyone but if you haven't taken one of Gunnar's courses and you consider yourself a security professional, then you need to smack yourself silly as the opportunity to learn from him is immense...

Communication and alignment isn't just a problem between IT and the business as it also exist between those non-technical IT employees and those who actually write working software...



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

Enterprise Architects should always avoid needless repitition, unless the repitition is needed...



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

Perhaps the "orders" are more like a process.

You want to solve a problem but are unaware that there is knowledge that would help.

You have a sense that there must be something that will help, but you are unaware of where to find it.

You know where it is, but you do not have access to it.

You have access to it, but do not understand how to make it work.

You get it to work, but find out that it is not what you thought.

Don't bother fighting the process, embrace it no matter how retarded it may feel...



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

Do analysts suffer the same economic pressures as the rest of us?
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.

WSO2 Identity Solution now feature-rich with OpenID
Good to see that both OpenID and CardSpace are staying competitive. Of course I predict that CardSpace will beat OpenID in the enterprise...

To tell or not to tell
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

Does EMC contribute to open source?
I wonder if Alex Fletcher, James Governor, Raven Zachary or others know the answer to this question?

Are software vendors aware that developing software in India causes customer dissatisfaction?
Here is one post that Oracle, Sun and HP will exercise their right to remain silent on

CISSP in New Delhi
They should instead consider attending their local Delhi chapter of OWASP so they can learn security beyond the surface.

Registered Tables is Fugly
Wouldn't it be interesting if you could not only register a SQL table, but also a directory service exposed via LDAP?

Feature driven development and insecurity by design
I wonder if OWASP needs to create the Secure Project Management Project?

Externalizing Authorization
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

Technical security as an afterthought is so Web 1.0
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?

Have you observed the uptake of the word agile by lots of enterprisey folks whom are more than capable of using it in a sentence but otherwise have zero clue about the values behind it...



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

I recently noticed a trend of how architects perform their jobs that I haven't heard discussed anywhere else...



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

Figured I would share a perspective as to why the IT Architect ranks should be reduced in large enterprises...



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

Have software vendors considered the possibilities of delighting their customers by supporting Active Directory more deeply...



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

Does EMC contribute to open source? I know that Microsoft, Oracle, BEA, IBM, CA and pretty much everyone else on the planet that is a large IT vendor does, but I have yet to hear of any meaningful contributions from the folks at EMC.

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?

Software vendors should seriously reconsider developing software in India. I figured I would share a perspective not discussed...



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

Do you work in an IT shop where there are two project managers for every developer?



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 perceptionbusiness expectations and needs to incorporate something about actually knowing more about the details of which you manage.

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?

There is an interesting behavior in large enterprises where the vast majority of enterprise architects cause numerous impacts to software development by their behavior...



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

On several occasions, I have asked Kim Cameron, Mike Jones and others to talk about CardSpace from an enterprise perspective as the conversation to date has been somewhat consumerish in nature. Luckily, Microsoft blogger Curt Devlin stepped up to the challenge...



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.

This tells me that Kim and Mike need to redouble their efforts and focus more on selling internally as well. How many Microsoft events where the likes of Chris Winn, Sean Lewis and other security folks from Microsoft take the opportunity to talk about cardspace? Do you think my employer has been formally briefed on it?

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.

In order to truly understand the ecosystem of identity, one needs to be aware of industry-vertical settings. It is no longer sufficient to simply attempt to find an enterprise architect to pitch your value proposition to. If software vendors such as Neustar, Ping Identity and others figured out that they need to speak to ecosystems as well as individuals, then more progress could be made.

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.

The Identity Management crowd who has their super expensive provisioning tools forget to talk to customers about problems within an ecosystem that weaken security and only focus on local concerns. We all know that enteprises are horrible in terms of timely provisioning and do an even worse job of de-provisioning users once they either left their employer or have changed roles. Reality says that if an enterprise is exposed internally, if they also need access to other systems in other enterprises, the problem only gets worse. Have you ever heard Nishant Kaushik or others from Oracle talk about the importance of federated provisioning via SPML? What would it take for Pat Patterson to openly declare when Sun IdM runs out of juice and for folks to realize that they need something else?

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.

I am of the belief that many enterprises have no issue becoming relying parties where the identity provider resides elsewhere. I do believe that the problem that isn't discussed is the infamous whose going to pay for it?. Reality says that the best model is for the users themselves to pay any fees desired by identity providers since they not only have the relationship but also choice in which one they want to use. This of course is contradictory though to past practices.

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?