I’m ok w/this “urged audience members to embrace competition and open systems. Control and exclusivity in business settings will be replaced by speed and innovation; his call for early info sharing “hang it all out, compete where you can” is self-serving
IT innovation is starting to be funded in this VC like manner: “think of ventures or innovations as real options. A real option is a toehold investment that buys you the right, but not the obligation, to make a subsequent investment when you know more.”
“Consider the ways that high fuel and energy prices could benefit your organization..maybe $4.00 gasoline leads your company to institute saner telecommuting practices, which leads to lower operating costs, better morale, and higher productivity.”
Archives for June 2008
As I’ve been waiting for the grass to get dry enough to mow, I did some spring clean-up here at elemental links. The two things that will be noticeable to blog visitors (not feed subscribers) are a long-overdue category consolidation — it was as tedious as it sounds — and the posting of my delicious links on the site. Hopefully the link-post job will work, because I removed all duplicate link splices – Feedburner and FriendFeed.
In addition to the clean-up activities, I also pulled some posts over from my Business-Driven Architect blog. You could say I’m working on my ‘source of record’. I don’t think those posts will show up in the feed, because I posted them here using the original post date. The new old posts are:
- Tammy Erickson: Taking the offensive in recessionary times
- Six Sure Fire Ways to Sink your Enterprise Architecture
- Business-IT Integration Continued: IT Geeks on the Front Lines of Innovation
- Enterprise Architects, Professional Escalation, and City Planning
- From the Archives: IT Fundamental Truths
I think that’s it for now. If you are curious how the lawn mowing went, follow me on Twitter. I do tweet (converse) about business and IT as well.
This post on men writing code from Mars while women write more helpful code from Venus caught my attention this morning — must be a sign that it’s Friday of a long week.
“Emma McGrattan, the senior vice-president of engineering for computer-database company Ingres–and one of Silicon Valley’s highest-ranking female programmers–insists that men and women write code differently. Women are more touchy-feely and considerate of those who will use the code later, she says. They’ll intersperse their code–those strings of instructions that result in nifty applications and programs–with helpful comments and directions, explaining why they wrote the lines the way they did and exactly how they did it.
The code becomes a type of “roadmap” for others who might want to alter it or add to it later, says McGrattan, a native of Ireland who has been with Ingres since 1992.
Men, on the other hand, have no such pretenses. Often, “they try to show how clever they are by writing very cryptic code,” she tells the Business Technology Blog. “They try to obfuscate things in the code,” and don’t leave clear directions for people using it later. McGrattan boasts that 70% to 80% of the time, she can look at a chunk of computer code and tell if it was written by a man or a woman.”
The post then goes on to tell of Ingres’ effort to instill coding standards to make the code “more user-friendly and gender-neutral”. Now, I can clearly recall being in a code review of developer who defended his use of binary-addition to decrement a loop in COBOL as “intuitive to him” and “the only way he thought of doing it”. Needless to say, we (a mixed gender group) asked for a change to make the code “intuitive to everyone else”. But, this was clearly an exception — and why I remember it from long ago — and I never considered it “a guy thing”. Just a “that guy” thing.
So, my question is what do folks think of the above? Is the need to prove code cleverness a geek thing? Or, a guy geek thing? And is understandable, maintainable code a girl thing? Or, is it all a matter of style, time and environment?
“Have you listened to the SOA Consortium’s SOA
Center of ExcellenceCenters podcasts yet? Day two of the March member meeting was focused on SOA Centers. Specifically, we set out to explore the mission, structure, skills, funding strategies and lifecycles of successful SOA Centers. On lifecycle, we were looking to answer the question of how long a center should exist and if/how it morphs over time. “Build to last, or build to blast?”
The SOA Center morning started with individual talks by Melvin Greer of Lockheed Martin and Rich Reba of CSC discussing their SOA Centers. Following those talks, David Butler of HP and Bruce Henderson of Savant joined Melvin and Rich for a roundtable discussion on SOA Center skills.
Before I go further, I should explain my edit of ‘Center of Excellence’ to ‘SOA Center’. Often, the connotation of a ‘center of excellence’ is a small, expert team that acts as a single source service provider. This was especially true in the early days of data warehousing and enterprise integration. However, SOA is a pervasive strategy (PDF warning) spanning/bonding business and IT. As such, our presenters made it clear that the ultimate mission of the SOA Center is to develop SOA competency (excellence) throughout the organization. In the case of CSC, that competency development directive extended to CSC’s customers.
So, think of the SOA Center as an incubator, rather than a manufacturer. What then is the SOA Center incubating, or as the blog post title suggests, accelerating?
Melvin Greer states his SOA Center is responsible for altering the behavior of IT professionals in order to be successful with SOA. In his presentation, Mel builds on the metaphor of Lucy Van Pelt’s 5-cent advice stand, speaking to common SOA disorders and listing the symptoms that indicate a competency center is needed. To hear Mel’s entertaining and insightful talk, go here.
Rich Reba shared that key to his SOA Center is the generation, and then fulfillment, of SOA demand. In his presentation, Rich describes the build out of CSC’s SOA Center in the context of building CSC’s SOA Business. Rich’s step-by-step story from vision to implementation is full of lessons applicable to enterprises, government agencies and service providers. The concept of SOA Center as demand generator recurred throughout our day. To hear Rich’s information packed talk, go here.
During the roundtable, our panelists spoke of a variety of skills required to build a SOA Center (political awareness, evangelism, communication, business discipline, vision, organizational design) as well as another list of skills required to operate a SOA Center (project/portfolio management, service design, business knowledge, technical aptitude, communication, teaching, governance). While the panelists had different points of view on specific skill needs, they agreed that a given organization’s SOA Center should be comprised of the skills most likely to accelerate value delivery. And, that the SOA Center’s contribution should be measured in financial terms. To hear the roundtable conversation, go here.”
If you’d like to share insights on your SOA Centers, have comments on the podcasts, or would like to engage in a SOA Center leader peer discussion, please leave a comment/trackback here or on the SOA-C blog post, or drop an email to bmichelson at elementallinks dot com.
[Disclosure: The SOA Consortium is a client of my company, Elemental Links]