Monday, June 30, 2008
Electricity Addiction, Green IT and Declarative Living
The notion of Green IT is starting to resonate in the halls of corporate America, yet the story isn't fully baked. Wouldn't it be interesting if industry analysts such as Tom Raftery and my peers who have been assigned to make IT greener didn't just talk about power consumption in the data center but instead made it more personal.
What do you think would happen if they all attempted to ween themselves away from electricity for just one day? No computer, no car, no TV, no crackberries, no telephone and so on.
Have you ever noticed that the moment an enterprise wants to start an outsourcing initiative, they hire natives from the country of destination (I wonder why this popular practice doesn't violate EEOC). For example, if you outsource to India, you can usually find someone from India as part of the decision making team. Shouldn't the same thing occur for Green IT?
Imagine taking folks from Pennsylvania or other parts of middle America who are Amish and asking them to consult on power consumption in corporate America. If you can't find enough folks who are Amish then consider those who are pious observant Jews. Devout Judaism says that people don't manipulate electricity for about 24 hours each week (sunset Friday to night Saturday) known as Sabbath. It becomes forbidden to drive, use public transportation, ring a doorbell, answer a phone, use a microwave oven and most certainly no computers.
I suspect that suggesting someone be on the outsourcing team from India is politically acceptable yet suggesting that we choose someone from a particular religious background to be on the green IT team is politically incorrect yet they follow the same footsteps. I guess enterprises have no choice but to reinvent the wheel and to not harness the knowledge of others built over the last couple thousand years...
Has any vendor ever appeared in the Leaders section of a Gartner Magic Quadrant without paying fees?
Sunday, June 29, 2008
How come enterprises don't ask their software vendors for bug-fix only releases?
Imagine what would happen if all the enterprises that use products developed by Microsoft, Oracle and Sun encouraged them to create a bug-fix only release. What would be even more intriguing if these vendors asked customers to enumerate all bugs they know but haven't reported and they would allow them to vote on priority themselves without any internal interpretation.
Even more intriguing would be the commitment from these same vendors that they would spend an entire six months on bug fixes and bug fixes alone. This activity could have several potential positive outcomes:
- Software vendors who have traditionally delivered high-quality software can finally demonstrate how high quality their offering is in a very transparent way. Likewise, they could compare their competitors approach and how they fumbled
- Security bugs may actually get fixed, making the OWASP crowd work harder to find faults in major enterprise applications.
- Sometimes it is hard to tell what the ratio is between the fixing of bugs, and the introduction of bugs. Vendors themselves will finally be able to quantify and improve their own practices
Azul Systems and XML Processing
Let's analyze Peter's comments:
- The system in question was a "SOA style" data movement application which extracts data from various systems, transforms it into a canonical XML format and from there passes it on to other downstream systems. A lot, but not all, of the data transfer is done in overnight batches.
At first blush, it was not clear how much moving to Azul might help this system. there was some parallelism, but not an overwhelming amount, and quite a lot of file i/o. This coupled with the fact that garbage collection during a batch process is not often a big problem (since there is no user present to complain if the system stops to garbage collect for a few minutes) made me wonder how much benefit Azul would show. Undaunted, we started to test.
OK, if this customer were smart enough to realize that there is a value proposition in going beyond commodity hardware to specialized Azul appliances that accelerate Java performance, then what prevented them from figuring out the same thing for XML?
I wonder if the better answer in this situation would have been to use IBM's DataPower appliance? Getting XML parsing and transformations out of software onto an appliance wouldn't just result in a 5x increase but in many cases, 100x increase! While I understand that Peter would have gotten fired by suggesting such an approach, it would be interesting to understand why the customer was asleep at the helm...
The Evils of Active Directory
Let's analyze his posting in order to understand where he went wrong...
- The problem is that Active Directory basically requires organisations to own all their own infrastructure if they want to achieve single sign-on across all of these products.
- Internally at Readify we are seriously looking at the costs of our IT organisation and we would love to be able to host Exchange with one hoster, SharePoint with another (not talking about SharePoint as a TFS dependency here), and probably self-host our TFS server, but possibly up on something like Server Intellect, or GoGrid.
- The problem is that all the subtle AD dependencies in this products makes it difficult to really commit to that course of action. If we decide to install products in workgroup mode (or give them their own AD as required by the hosters) what are we exposing ourselves to in the future if one of the product teams decides to take a hard dependency on AD.
- Where are the investments that Microsoft is making around technologies like CardSpace and simple Username/Password authentication over SSL in all their products which will allow their customers to distribute their IT assets in the cloud.
- Until Microsoft takes multi-tenancy and hosting scenarios seriously its not going to be a reality for a lot of organisations.
Saturday, June 28, 2008
Marketing guys should not blog...
I was looking at the blog of Ram Appalaraju of Azul Systems and wonder if he realizes that blogs aren't about thinly-veiled marketing material. At no time does he provide any opportunity for customers to engage in a conversation. In his own words:Let me highlight some of the problems and pitfalls that come up with the vendors when touting their product performance, so I figured I would do the same.
- In the case of Vega 3 it’s not a bad story: 70% higher performance than Vega 2, and a whopping 5X faster than Vega 1.
- It is also a hard point to prove outside of our own headquarters, although some customers may choose to compare their existing Vega 2 deployment to Vega 3.
- Typically customer use cases validate the benchmark or initernal company specifications (the two listed above), but then go much further in telling the whole story. It may be one thing that it’s 5X faster, but if it takes 10 weeks to get up-and-running it’s something different.
- However, these are usually the hardest pieces of product data to obtain because if the customers have achieved great things they want to hide it from their competitors, and often companies have strict policies on what information can be shared externally.
More importantly, there is not a single policy that prevents any of my peers from publishing a benchmark! However, there are hundreds if not thousands of contract clauses from many vendors that prevent me from sharing them. Of course, vendors would like for them to be published only if they are positive, but otherwise attempt to handcuff the enterprise if they aren't so shiny. I wonder if any customers of Azul would be shutdown if they published their own unfavorable information?
- I guess the point I'm getting at is that we marketers can throw a lot of "evidence" and supporting numbers at you (such as the above 3) to show how great our product(s) is, but unless a product meets your exact needs, our numbers and evidence don't provide much value. That’s the other fun part of my job: making sure the products meet your needs!
Am I missing something?
Friday, June 27, 2008
Yet another reason why knowledge management is problematic...
Documentation at any level is boring and probably the last thing anyone technical wants to work on. Consider the fact that us enterprisey architects who hang out with process weenie project managers can concoct ridiculous deliverable dates that require developers to work nights and weekends, do you really think that even if they made the effort, it would be of high quality?
Recently, I had a conversation with a developer whom I will refer to ask DEMO. If I were to ask him for documentation, he would send me the source code of his latest creation and want to talk to me about all the cool things he thought about. In his mind, why should he write documentation when the source code is documentation and more complete?
On many occasions I have suggested us do pair programming together and he resists the idea. I don't think it is about my competencies but more about having someone else step on his masterpiece. Besides, I might give him feedback that he really isn't interested in hearing and will have to oblige for perception management purposes. I guess I am blessed at some level, in that he would probably get torqued if it were someone other than me asking in the sense that he knows I will respect his pride in understanding the depth of a solution, something that is increasingly lost on others.
Interestingly enough, I have watched way too many developers attempt to take pride in their work only to watch those on the other end simply shut down and play with their Crackberries. I wonder if those who champion knowledge management within large enterprises have ever heard of the Seven Habits of Highly Effective People where it encourages seek first to understand, then to be understood?
So if knowledge management doesn't do a better job of understanding the human aspects of technology, does it become shelfware doomed to mediocrity? Has anyone ever thought about why developers hide out at their desk and blow off meetings? I bet you haven't figured out that compilers aren't judgemental, but those attempting to implement knowledge management may be...
Thursday, June 26, 2008
Emphasizing Strengths while not bothering to fix weaknesses
Have you ever thought about the annual review where your boss has to say something positive and something negative? The focus on the negative is worthwhile in situations where your weaknesses isn't at the level of mediocrity. Have you ever considered that this type of conversation is a trap and in all reality a good predictor that your boss may be incompetent?
Consider what would happen if your boss were truly doing their job. They would probably deploy you in a scenario that only leveraged your strengths while not exposing your weaknesses. If you are having this conversation, the odds are good that your boss has drunk the HR Kool-aid and is guilty of treating you like a pluggable FTE resource and not a human who has strengths and weaknesses.
Most folks are good at a handful of things and utterly miserable at most. I am great at deeply understanding architecture (enterprise, software, infrastructure, etc) and software development but don't have an operational grain to my persona.
If you have ever met me in person, you would know that the odds are good at deploying me in a combat situation would result in a way as my personality, physique and constitution are all suited. Likewise, you would also know that spending time teaching me to be a horse jockey and betting on me to win a horse race would be ridiculous.
It is far more lucrative and fun to leverage your strengths instead of attempting to fix all the chinks in your armor. The choice is between multiplication of results using strengths or incremental improvement fixing weaknesses that will, at best, become mediocre.
Enterprise architects need to acknowledge that at any level, being incremental is a mental disorder. Besides, if you focus on strengths, morale will improve and you may actually become successful in hiring top talent vs hiring average folks and relabeling them...
Wednesday, June 25, 2008
Thoughts on Industry Certifications
My preliminary take on the marketplace is that the folks who make the effort to take certification exams tend to be located in North America, Western Europe or Japan. I cannot find much evidence of folks studying for exams in India, China, South America or Eastern European countries. It can be assumed that many folks in India, China and Brazil are highly credentialed but otherwise junior in their experience and ability. Maybe their participation will increase once the masses improve. What is more curious is the fact that females aren't studying either.
In my own network, I started to noodle how many female software security professionals I personally know and could only come up with Holly, Diane, Melissa and Sherry. I would like to think I am connected, but when I can't count on two hands, I know something has gone horribly wrong. The real question is what actions need to be taken to make this better...
Enterprise Architecture and Time Wasting Activities
Many enterprise architects spend a lot of time on nonsense, much of which isn't our fault. Many would agree that there is no incentive to use time well unless you are paid on commission. The world and more importantly your employer has agreed to shuffle papers during core working hours and since you're trapped in the office for that period of servitude, you are compelled to create activities to fill that time.
Enabling conversations is one activity many enterprise architects do on a daily basis, some of which are very beneficial while others are solely for perception purposes and otherwise add nebulous value. The ability to socialize new concepts is vital to selling a strategy, but what is more important?
Nowadays, the IDE of enterprisey architects is PowerPoint and Visio where if you were to ask yourself which has a better return, the output done in Visio tends to be more beneficial yet many of us spend more time in the former. So, if us enterprisey types create so much PowerPoint, what are we guilty of if we compel others to pay attention to them even if only in appearance?
Socialization has benefits, so let's do more of it. Likewise, if you are in a hole, then digging more is also beneficial. Seriously, when will enterprises start to ask themselves when socialization becomes a time wasting activity...
Tuesday, June 24, 2008
Enterprise Architecture: Repeatable Indian Outsourcing Mistakes
We understand the difference in culture and to the meaning of the word Yes and how it differs in America vs India. There however is another pattern that happens that is more subtle. Even in situations where you have a full army of staff from an Indian outsourcing firm where you are more than outnumbered and even have more staff on hand than if it was a US based company doing the work, managers still make repeatable classic mistakes.
My general observation is whenever this happens, the pattern tends to be a manager providing what he feels to be a specification without actually documenting it. Likewise, regardless of supposed seniority, the vast majority of developers in India are still junior and therefore will implement either what they understood (distinct from what was said), what they are able to do with information received (more about ability or lack of) in the way they imagine is best (usually full of common but otherwise worst practices). All of this goes away once us Americans get a clue as to how to specify software correctly.
In the early days of my IT career, I used to participate in sound-offs where the car I drove has 2,000 watt sound system. The license plate was hearme. It is natural to want to be heard but it is important to acknowledge that the opportunity for this to become reality is slowing fading away. Americans have an increasingly small window of attention where everyone is multitasking as the sole method of maintaining work/life balance. Not everything can be distilled into a 15 second sound bite. When combined with junior personnel offshore, it becomes increasingly important for enterprises to understand how to write better specifications as tribal knowledge no longer scales...
Monday, June 23, 2008
Why innovation isn't occuring in enterprise software...
Enterprises are doing themselves a disservice by elongating procurement cycles. Has any enterprise architect ever considered the cost of sales for your software vendors? Let's say that you are an enterprise architect who has been indoctrinated by Robert McIlree into heavyweight process to the point that you understand nothing about technology and become hooked on vendor presentations like a crack addict. Instead of looking at open source software such as Liferay Enterprise Portal which is freely downloadable and doing your own proofs of concept, you instead decide to have an enterprisey vendor do it for free. They send a sales executive who needs to make $150K a year along with a sales engineer who also needs to make the same.
These two individuals do multiple demos. First to you in order for you to feel comfortable, then to a small team of interested parties and then again for the official POC kickoff. In the meantime, they have spent lots of time travelling back and forth on airplanes, trains and rental cars. Let's not forget that they would have needed to take you to lunch at least once or twice. By now, they have spent at least $10K on expenses not including salaries. We decide to do a proof of concept where the goal is to demonstrate low-hanging fruit and you put up a demo that is the equivalent of Hello World. They could have done this remotely but it was important to you to have lots of face time with the vendor. Let's now add the cost of hotel and meals to the equation.
Anyway, you decide to make the move to purchase the software, but unlike in the past you have to jump through more hoops (better known as governance). What used to take three months now takes nine months. Remember, the vendor hasn't seen a single nickel for their efforts. You finally make it through all the hoops and are ready to get the deal executed and then a reorg occurs and new folks are involved and need to be brought up to speed. Yet another round of demos.
I hope you are starting to see a pattern emerge where if the cost of software stayed the same yet us enterprisey architects are causing more expense for enterprise software vendors, then how can they possibly have enough monies left to actually innovate...
Enterprise Architecture: Should EA have its own manifesto?
The Agile Manifesto for software development has been embraced by the masses of tired developers who simply want to develop high-quality valuable working software for their business customers and have grown increasingly disgusted with the chock-a-block so-called best practices vomited by process weenies who have been successful in making IT mediocre and on the path of no return.
If you aren't familiar with the Cluetrain Manifesto, you would come to understand that hyperlinks subvert hierarchy yet EA in most shops neither provides the value it originally sold nor even enables the strategic intent of the business. Nowadays, it seems as if EA serves itself.
Have you seen what the vast majority of enterprise architects in the blogosphere are discussing? Maybe we need to focus on the basics, you know the way we live, work and interact, otherwise known as the human condition. Can we really be successful where we have open cubicles, no privacy, stifling on bad recirculated air, crackberries as the norm for communication, flourescent lighing, lots of extraneous noise and a lock on all the office supplies.
Few people in corporate environments nowadays even have one scintilla of common sense nor practice random acts of logical thinking. I used to think that Information Security folks where the last great hope, but my faith is quickly waning. Even they have went to the dark side by insisting on clean desk policies. The next thing you know, they will be checking to see if our #2 pencils are sharpened.
A clean desk means that there is a strong inducement to reduce the latency of any document on your desk. Don't think deeply about any particular problem, simply heist your leg, add your smell and move it along. Anyway, in conversations with other enterprise architects, I can find tomes of processes but have yet to find a single architect who can articulate what values they collectively hold themselves to. I wonder if anyone cares to truly make enterprise architecture better or simply are blogging to promote the modern version of snake oil...
How can Indian Outsourcing firms improve...
One doesn't improve unless you take deliberate actions to do so. As a book author of several bestselling books including Java Web Services Architecture and Enterprise Service Oriented Architectures, along with moderating the Computer Book Authors Yahoo Group, the book sales in India are way down.
Logic would dictate in a growing market that book sales would increase and not decline. The only rationale answer is that folks are happily programming away using trial-and-error. If folks are into so-called best practices such as CMMi, knowledge transfer and so on, that you would at least make a better effort to learn from others. The value proposition of India can increase if and only if you not only compete on price but actually learn to program as well as Americans or at least at the same level.
Many Americans have spent countless hours in their basements after long hours at work writing down their thoughts to share with others and they aren't doing it to get rich. Did you know that I make only $0.75 for each book sold? Nowadays, this isn't even enough for us authors to visit MacDonalds and supersize (something I really shouldn't be doing anyway). Figured I would mention the economic aspects so that folks wouldn't get it twisted and think I am only promoting books. Reality says that if others in America are buying books but their Indian counterparts are not then whom do you think will stay ahead?
More importantly, if I have a bookshelf with lots of reference materials while folks in India are attempting to google for answers, with all other things being equal, who do you think can deliver software faster? So, my first recommendation would be for folks in India to stop asking their bosses at Wipro, TCS, Infosys, Cognizant, Satyam, Accenture or wherever you may be employed and start asking them to provide a rich book budget for their employees to learn...
Sunday, June 22, 2008
Links for 2008-06-22
This has to be one of Laurence Hart's best posts to date where he outlines how Documentum in the future will support SAML and XACML. It is encouraging to know that Craig Randall has this on his own personal radar. I am surprised that Ajith, Johnny, Cornelia, Alan, Mark or Sumanth didn't provide their perspective on this posting. I do suspect that John Newton and others at Alfresco are silently working hard to make sure that they beat EMC to implementation...
I wonder if James Robertson is available?
Todd Biske keeps Dave Linthicum honest regarding SOA Governance. Way too many industry analysts view SOA through the lens of products and refuse to expand the conversation. I would like to add one additional principle: Align your SOA to your enterprise information protection policies as so many so-called enterprise services miss this point.
What is your opinion of blogs and Wikis in an enterprise setting?
This reminds me of another problem of large enterprises ranting that they are having problems finding good people. Those folks only complain and are not part of the solution
The mail strike is tying up lots of stuff in Trinidad including stuff I have sent to friends and family. I guess I have to get on a plane and deliver it myself. Biche, here I come...
Alex Fletcher is an absolutely brilliant industry analyst. I would love to see Entiva merge with Elemental Links and both of them merge with Redmonk.
Indian Outsourcing: Is the concept of knowledge transfer a trap?
Words mean things and we need to stop overloading our vocabulary. Whenever we seek to share or transfer knowledge, we create information as a means of sharing it and often store the information in some other medium. Knowledge is personal and evolves. Likewise, what one currently understands as knowledge today, may over time become information. In order to land on the right mental model, we need to understand whether the United States Constitution is information or knowledge?
Is there a distinction between information management and knowledge management? Is your starting point the understanding of the distinction between information and knowledge? How would you classify the knowledge content of the Bible, the Holy Quran, Vedas or other scriptures?
Should documents be treated as information regardless of their role, their reification, their degree of social acceptance and their ability to impart learning? There are no clear boundaries between information and knowledge and the line depends on one's personal viewpoint along with how you negotiate the understanding with your circle. The distinction becomes less important as you become more comfortable with the core concepts and their application.
For those who practice mental masturbation, the question of whether we can have explicit knowledge at all will emerge. If explicit knowledge morphs into information as soon as you represent it, how will you treat stories, dialogs and reflections of what you know?
For those who understand the distinction between knowledge, wisdom and understanding, you will agree that knowledge is not understanding until it has been assimilated. Information is not knowledge until it has been communicated. Mabye, the we need to acknowledge several truths. First, people, even average and otherwise unskilled have much greater abilities to manage knowledge in their own heads than any software that currently exists. Second, knowledge nor information can be effectively harnessed without good people management which includes training, development and even succession planning, all of which needs to occur in a culture which values the knowledge inside people's heads.
So, what does your culture value...
Saturday, June 21, 2008
Should enterprises hire more stupid people...
The more you know the more likely you are to get bored. For example, if you know how to factor repetition out of your code, but the organization won't let you, then you will probably be bored out of your skull doing it the "low brow" way. This is one reason why organizations are reluctant to hire "overqualified" people. Such people tend to use their knowledge to "stir the pot", taking managers out of their comfort zone. Their code usually requires a higher-skilled person to read and modify effectively increasing replacement expenses.
It is not that every well-informed person is going to stir the pot, but a high enough percent will do it to give all a bad reputation...
Friday, June 20, 2008
Why IT no longer innovates...
So, is it a sad state of affairs when no one within the enterprise is innovating? Maybe the key message here is to get better at letting your customers innovate for you...
Links for 2008-05-20
The notion of an ISP being the holder of identity works in a consumerish model but fails miserably in enterprise settings. Likewise, for B2B interactions that involve licensing, indemnification or other constructs, identity needs to reside elsewhere. Of course this begs the question of why aren't other bloggers talking about identity other than in consumerish settings?
Gerry Gebel is a brilliant industry analyst. I wish Burton Group though in terms of XACML interoperability would stop focusing on how security vendors interoperate with each and focus more on how ECM, BPM, CRM, etc products can become XACML policy enforcement points. Some insight as to when Siebel, Peoplesoft, Lombardi Software, Intalio, Documentum and others will participate in an XACML ecosystem would rock.
What are your thoughts on certification of IT security professionals?
Wouldn't a better approach be if Documentum integrated out-of-the-box with LogLogic?
I really hate using the words leader and manager interchangeably, but ignoring this small point for a moment, this is a good blog entry on opportunities for IT executives to improve. The need for having high-level knowledge of architecture, security, infrastructure, compliance, data, QA, operations and so on is spot on. What would be even more interesting is if someone decided to do a survey to see how far away from this need most IT executives currently are...
Thursday, June 19, 2008
Enterprise Architecture: Why Business/IT alignment is elusive...
In practical terms, IT and business priorities must be tightly linked and spending must be matched to the company's growth strategies. There must be shared ownership and shared governance of IT projects. A lack of alignment can doom IT either to irrelevance or to failure.
The funny thing is that alignment alone doesn't bring along improvement. In fact, a narrow focus on alignment reflects a fundamental misconception about the nature of IT. Underperforming capabilities are often rooted not just in misalignment but in the complexity of systems, applications and other infrastructure. Complexity doesn’t magically disappear just because an IT organization learns to focus on aligned projects rather than less aligned ones. On the contrary, in some situations it can actually get worse. This begs the question of whether IT is somewhat premature in its need to expend energy to sound like the business vs simply working on ways to make IT better even if business doesn't understand the need.
The non-technical IT executive, especially those who are perception management oriented will spend money on developers who are dedicated to particular business units in order to improve alignment, yet these same IT executives will continue to ignore the need for standardization and upgrading of legacy systems. How can you be aligned if you are still doing worst practices such as COBOL?
IT in the pursuit of alignment in many cases has created a new labyrinth of new complexity on top of the old, making IT system enhancements and infrastructure improvements even more difficult to implement and leaving the potential to scale on the table.
One needs to ask themselves if they understand the difference between being aligned vs being efficient? Do enterprise architects ever emphasize simplicity or are they rewarded for managing complexity?
More importantly, alignment can never occur and enterprises cannot build effectiveness unless they hold IT and the business accountable for delivering expected results on time and on budget. Accountability is not a departmental concept but one that needs to be assigned to each and every individual within IT.
As an enterprise architect, I know that I have responsibilities over many agendas, but when are we ever truly accountable? Accountability requires at many levels more than just influence and almost always demands control. In today's world of governance, where everyone has a say, it erodes the ability to make anyone accountable.
True accountability reflects organizational changes. Executives get the information they need to measure IT progress, folks in are held accountable for outcomes, business folks and controllers give IT the resources it needs and then work closely with not just IT executives but IT leaders throughout the organization chart to give them the tools required to get the job done...
Wednesday, June 18, 2008
Enterprise Architecture: Proof is often not required...
Why can't we follow tradition as simple proof is a lot of work...
Is it a bad thing that there are no IT security generalists?
I am project leader for the OWASP Certification Project where the goal is to provide credible certification for software security professionals that is language agnostic and provides an effective measure of a security professionals practical abilities.
As an Enterprise Architect, I understand the importance of the ability for a security professional to articulate risk to IT and business executives, yet I am also equally passionate that security professionals should also have the capability to sit down at a keyboard and actually do something as opposed to just talking about. In order to accomplish this goal, it requires one to not only understand how the most popular security exam is deficient (CISSP) but to figure out how to make one with more depth, integrity and completeness.
The CISSP exam requires folks to understand physical security, cryptographic algorithms, network security and even civil law in the same exam. I wonder if being a mile-wide and an inch deep is serving the needs of business and the duty to protect or causing it harm.
Security is more than just taking overly simplistic exams and the testing of one's ability to memorize obscure facts. The funny thing is that many of the participants in OWASP are considered some of the best security professionals on the planet, yet very few even made the effort of becoming a CISSP. In my own career, I have achieved over seventeen different certifications, so don't get it twisted to think that I fear exams. I do however fear that the trend of IT security is following the worst practices of the past when IT managers used to require new employees to become MCSEs which translated into a lot of folks having book-level understanding of security and not practical abilities.
I am savage in the belief of the principle of show me the money. If you are a skilled penetration tester, can write secure code and can reverse engineer software, you are worth more than any CISSP. For those who embrace the mental disorder of hybridism and distillation, balance between these two are needed where true IT security professionals understand both not just one over another...
Tuesday, June 17, 2008
Even more untold perspectives on social networking within large enterprises
Many folks who participate in social networking are intuitive thinkers who rely less on process and/or distillation and more on vibes they feel. Wiki's are great tools to harness the thinking of this demographic, but may be sub-optimal for those who prefer more structure or guidance.
Many people within large enterprises when running across an unfamilar concept especially when it is paradigm shifting can sometimes gather that it is important and even relevant, but may struggle to understand why it is relevant. In order to make social networking truly an enabler and not just another unmanaged repository, enterprises need to spend more time on understanding its own social computing architecture before thinking about how to leverage social networking technologies.
Enterprises have well-defined business processes that sometimes aren't well documented. Some would conclude that Wikis are great for this challenge. None, however take the time to understand the process of communication and how information is best shared. The answers to this question isn't something that can be known in advance and even differs amongst enterprises of the same size, business vertical and geographic region.
Let's acknowledge that enterprises do a great job of producing documentation that sits on shelves. Are we successful if we manage to get 100K pages of information onto a Wiki? Publishing is easy, consumption is the challenge. Likewise, enterprises are caught in the trap of analogies and best practices where they will attempt to leverage the phenonena of the blogosphere and twist it to fit their own needs. Reality says that what works on the consumer side doesn't necessarily fly as an internal corporate tool.
Have you noticed that when a project is in trouble from a perception management perspective, folks tend to blame their tools? Just as a poor mechanic may blame his/her tools, the problem with social networking in large enterprises is that the problem may not lie in technology but in the nature of the business. Some enterprisey architects will think they have the answer to this dilemma by stealing pages from the business process management folks and think about taxonomies, classification schemes, roadmaps and so on.
One worst practice in enabling social networking is emerge with something that feels top-down and hierarchical. If you haven't read the Cluetrain Manifesto then you may want to understand that hyperlinks subvert hierarchy. BPM attempts to organize people and their work hierarchically where consumers within your enterprise tend to be more organic and go about learning, sharing and collaborating bottom-up.
Process weenies the PMI crowd results in something that will further increase the likelyhood of mediocrity. Focus has to be less on keeping the project running on time than adjusting scope to deal with the real challenges. Social networking sometimes requires folks to rethink their game.
One of the biggest challenges is finding a politically correct way to account for generational differences without landing in HR. The enterprise is filled with folks in positions of power who grew up without computers and Gen Y works who have been connected since kindergartner. Are you going to leave it to chance that these two demographics figure it out on their own in a timely manner or should something more deliberate occur to enable the value proposition of social networking within large enterprises...
Enterprise Architecture: Best Practices in Business/IT Alignment
First and foremost, the best strategy for enabling Business/IT alignment is to encourage IT literacy within the enterprise. It isn't sufficient for a CIO to sound like the business as the business equally needs to understand IT. Are you familiar with Stephen Covey and the Seven Habits. Well, if you believe in the principle of Seek first to understand, then to be understood, it is important to also believe that business executives need to know enough about IT to understand its value proposition. This should be based on worst-practices of IT constantly producing metrics and chock-a-block eye candy Powerpoint presentations that are a weak substitute.
Second, it is important to not use the words management and leadership interchangeably. If you are a business person running IT, then you are a manager, nothing more, nothing less. Strong technical leadership is lacking in most enterprises as most CIOs are not really that technical nor really understand the business. Hybridism is a mental disorder.
For enterprises to thrive, they need to hire a true Chief Information Officer and acknowledge that choosing one is more difficult than even choosing a new CEO. Likewise, a CIO needs to be tightly coupled with highly competent Enterprise Architects who understand how to get things done and enable scale.
The third practice is to acknowledge that IT needs to stop twisting the meaning of words in conversations. Many bloggers find joy in reiterating the various definitions of enterprise architecture, which if thought about correctly causes folks to further twist the meaning. Luckily, there is one demographic that doesn't practice this worst practice and that is IT security professionals who all have a common story.
Walk up to any IT security professional in any enterprise and ask them about Alice, Bob, Eve and Mallory. These names always play the same role and at no time do security professionals get creative and substitute one name for another name. The ability to have a common unwavering story that is understood by all where nothing gets lost in the translation is key to alignment.
Many enterprise architects do a wonderful job of presenting accurate information and do so with integrity, yet much of the information gets lots in the translation. Part of the problem is that IT-based business models and internal proposals tend to only focus on the positives causing most IT folks to not bother to understand what the technology can and can't do. Many enterprise architects are savage in the pursuit of happy path architectures and are jeopardizing alignment because they aren't learning about what can go wrong and therefore aren't taking advantage of the opportunity to educate the business. Sooner or later, everything goes wrong and becomes a surprise to the business which simply shouldn't happen...
Monday, June 16, 2008
Enterprise Architect: To be blunt or not to be...
Blunt: "That's not what I meant, you stupid idiot. Read it again!"
Socializer: "It seems there is a misunderstanding. Let me attempt to rephrase it..."
After repeating yourself in what feels like an endless loop in a language where there is no BREAK statement, you sometimes are frustrated and loose your cool. Sometimes folks who have zero clue travels from one topic to another and brings up the same points over and over. The thing that I find works best is to not let failure deter you. Don't focus on the amount of time you are wasting with someone who isn't willing to put forth equal or greater effort to understand the message, just very diplomatically rephrase it one more time.
If you truly can't stand it anymore and are considering throwing in the towel, consider walking out and avoiding the temptation to insult. Even better, if you are talking about software design, move it along and tell folks you are going back to your desk to actually write code.
Consider, maybe they are in a role where they actually understand and have good intentions for being dense. It could be a situation where they are helping others understand that otherwise would be too embarrassed to ask questions. Maybe they actually understand and have done homework but don't know when to stop. If you cannot detect the game of mental masturbation, then you too become the idiot...
More Untold perspectives on social networking within large enterprises
Continuing the previous discussion on social networking within large enterprises. Have you heard of service-oriented architectures (SOA)? One of the major value propositions behind is to decouple the producer from the consumer in order to enable scale. This principle holds true in terms of scaling social networking within large enterprises as well.
Within your enterprise, are you forced to standardize templates such that if you do a Powerpoint presentation not using the kid-tested, mother approved template, you will get yelled at? Think for a moment about this way of thinking and how it may need to change to make social networking scale. For those reading my blog, do you think I will change the look and feel of it, because a particular individual wanted to see it a certain way? Even if I were braindead enough to spend more than one second thinking about it, I couldn't simply keep up with the need for multiple versions that I would need to maintain in order to handle all those consumers.
My blog scales because I am loosely-coupled between producer (me) and consumers (those who read my blog). The analogy says that social networking within large enterprises would work much better if my boss didn't move the consumption problem back to the producer. What if he figured out that if he wanted to see things in a certain way, he could simply transform it using whatever technologies he chose and more importantly, he could allow me to become more productive in publishing content in the way that best works for me?
- NOTE: For those boneheads who will get it twisted, my boss is one of the coolest folks on the planet and doesn't suffer from problems outlined above
Have you noticed that many consulting firms such as Accenture, Bearingpoint and even McKinsey will talk about the importance of social networking. Do you think that they have the liberty to publish and present information without leveraging their fine PowerPoint templates? Could a consultant from one of these firms maintain the goals of perception management while ignoring worst practices such as using PowerPoint bullets? Could they do a 2.0 style PowerPoint communication with strictly images (and no bullets) with little internal churn in doing so?
I guess my point is that social networking isn't about tools or even the process around tools, but more about removing the impediments for capturing knowledge, providing insight and enabling conversations that lead to implementing the strategic intent of the business in an agile way.
Too much of the conversation around social networking within large enterprises to date has been about tools (e.g. wikis, blogs, instant messaging, etc) and we have let the process weenies once again allow something that could be really game changing to be reduced down to mediocrity...
Browser Security: What if Microsoft and Mozilla worked together...
1. Microsoft is doing the right thing when it comes to CardSpace and has implemented an identity selector in Internet Explorer. The challenge is that Microsoft hasn't done much evangelism of this technology within the enterprise marketplace. It would seem as if Cardspace could be the mechanism that eliminates fugly passwords, prevents spoofing and hijacking of passwords yet if no one knows about it, the ecosystem can never be secure. With a little bit more evangelism and for the Mozilla folks to not think of an identity selector as an add-in, browser security can improve.
4. In the same way that Cardspace runs in its own process, why can't Microsoft make all plugs-in installed via ActiveX do the same? Separating out plug-in execution could provide the necessary constraints and even can allow for policies to be applied. It shouldn't be enough just to sign something, but should require user consent to run in the same address space of the browser.
Of course many of my thoughts have tons of holes and the point of sharing them isn't for folks to throw daggers at my ideas, but to focus on making browser security better...