Chinese Definition of an IT Architect

Thanks to Dave Rose for pointing out this definition from a China Architect Summit brochure.  My apologies in advance to all the really bright women IT Architects.  I’m just quoting.

“Architect is the guy who’s responsible for the soul of the software — architecture. His philosophy, his thought and his skill sets; all of these combining has profound impacts on the lives of not only the systems but the people who are using them.”

This makes being an IT architect not just an intellectual exercise, but a spiritual experience too.  :-)

Offshore IT Outsourcing Not Necessarily What its Cracked Up to Be

I recently came across a somewhat provocative article on the issues companies face when they decide to use offshore resources in the online version of CIO magazine.  In the article IT Outsourcing System Is Broken, How Can Service Providers Fix It?, Andrew Wasser, the the associate dean of the Heinz College’s School of Information Systems and Management at Carnegie Mellon University goes beyond the usual issues of language and cultural differences into some issues I had not considered.  In particular, he asserts that:

  • The demand is so great that no IT vendor can really say they only have the best of the best people.  They all have to reach down below the top students in the top tier schools.
  • The hiring practices of most IT vendors resembles a formula that weeds out the people most likely to be a source of true innovation.  They tend to hire only those students who have always done exactly as they were told their entire life.  He believes that type personality is unlikely to take the risks required to bring forward innovative ideas and make them a reality.
  • The companies choosing offshore resources are partly to blame because they don’t really want to be bothered with their offshore teammates.

Here are some quotes to get you thinking.  On recruiting:

“In the beginning when you talked to a tier-one sourcing [firm], they would tell you, “We get the best of the best.” They made offers only to the top 0.5 percent at the universities. And they may still tell you that today, but the reality is quite different.  Because of increased competition and a shortage of talent, they have had to go much deeper into the pool of students and go to second and third-level schools. They are no longer getting the best and the brightest.”

On offshore teams as a source of innovation…NOT:

“We see continued frustration from clients that these people are really good order takers, but they are not problem solvers. They are smart — no question — but they are not the strategic partners they had hoped they would be…..”

“One issue is what I call the “filter effect.” The sourcing firms go to the same affiliate universities and programs year after year. The HR people have a formulaic set of attributes they are looking for. Did they take discrete math or programming one and two? How were their grades? When they can check off all the boxes, they make an offer. So they are getting students who have done exactly what they were supposed to do. They graduated from high school with good grades. They told their parents they wanted to study history or art. The parents said, “Great, but you’re going to be an engineer.” They have no gaps in their studies, no blemishes on their records, their extracurriculars are all in place. And when they finally graduate with a chance to do something innovative or unique, they once again do exactly what mom and dad tells them to do — apply for a job at IBM or Infosys….

Then the firms say, “Why aren’t my people innovating?” Well, you filtered out all the people who might innovate — the guy who took time off to hike the mountains or the girl who tried to start her own t-shirt company or the student who stumbled freshman year because he was interested in guitars and girls. You hired people who are good at doing what they are told and now you wonder why they’re only [a] good order taker. “…..

“Once you get into these sourcing companies, they all follow CMM-I or Six Sigma or ITIL. They put in place all these SLAs and metrics and procedures and policies. I have no problem with process frameworks. They have been great for our industry and turned what was a craft into a science. But they do not foster innovation. No one is willing to say, “Hey this might not meet the SLA or it’s not ITIL, but here’s a novel way to address a business need.” “…..

“One of the issues particular to offshore outsourcing is what I call the “texting effect.” Whether you are in China or Mexico or India, the [English] speaking and listening and writing skills aren’t always great to begin with. Adding to the problem is that engineers are notoriously weak communicators. And if, on top of that, the engineer doesn’t understand the business drivers, they’re never going to speak the real language of the client. “…

On the topic, “Are the customers responsible?”

“The client holds a whole lot of responsibility. They often don’t want to spend much time with the Indian guy — they don’t think he’s that fun, he has an accent, and he can’t talk about the Syracuse win last night — that’s a problem.

That is tied up with what I call the “context effect.” The client tells the vendor what to do but not why they want it done. If I tell you, “Move this box from here to there,” and you do not know the context, all you can do is what I tell you. But if you understand the bigger picture, you may realize you can discard some of what’s in those boxes, some of it you can scan, and some you can leave behind. There is so much value in understanding the real meaning of what you are trying to accomplish. Context can be especially difficult to gain when a development center is in Monterrey or Chennai. But it is the client’s responsibility to share that business context. “

After both good and bad experiences with globally dispersed development, I was intrigued by what Mr. Wasser had to say.  I must also admit that my first instinct was to agree with much of what he had to say.  At this point, I decided to consult with my US-based and overseas colleagues from projects over the last few years to see what their reaction was.  Here’s a sampling of comments I received.  In some cases the English wording is a little rough but I have left the comments in their words.

These comments are from a friend who grew up and began his IT career in India and who later came to work in the US.  He’s often played a liaison role between US-based teams and teams in India.

“I have been to a few campus interview….and the focus was to hire the brightest not necessarily the creative/innovative. In India from a cultural perspective (and the article correctly points out) more stress is on doing good academically not necessarily on other fronts – one reason you would see why India isn’t very good in many sports’. Some companies do stress on analytical skills but people with creative skills (musicians, artists etc) are often left behind….

There is a set of people who will take an initiative and ask ‘why’, however that is a small layer, most will do what is told. With the demand what has been generated for skilled IT folks in India and with increased expectations of the employees/customers and attrition, lot of people that have been hired aren’t necessarily the best and are happy in doing what is told to them. The article talks about the language and weak communicators which again is true and  in fact there reason why I first got a chance to come to US. I was responsible for bridging the teams in India and the US….

The clients seldom want to get involved with what is happening offshore as long as the work is getting done with reasonable quality, that has been my experience.”

From a colleague in China, there was interest but more questions than a point of view.

“This is really a good article to let us think about some offshore scenarios, it gives us another perspective to look down the IT strategic. How can IT drive business or business drive IT?”

I got these great comments from a co-worker who grew up in India but is now living and working in the US.

I’ve always maintained that there is a cultural-context to the problem at hand, and to come up with an innovative solution, physical & mental proximity to ground-zero of the problem, is very important. This is perhaps the most challenging, in the case of outsourcing engineering projects offshore, among others including, cultural, language & time-zone differences!  As for cultural-differences, it’s important to note that, although solutions to a variety of engineering (social, environmental  & economical) problems may have a business-value, the ability to reap the value depends on the business-maturity of a particular culture & hence it’s willingness to take on such problems. So it’s not surprising at all that there is little value to outsourcing especially knowledge based work, to locations where the culture does not have the business-maturity to reap the benefit  and foster innovation. In addition, the culture of automation & instrumentation is still far-fetched in cultures that do not share, the long history of industrialization which should be taken into account, & factor the necessary training requirements (communication, planning, execution & delivery of engineering projects) to make the best of outsourcing  work, off-shore.

He also took aim at one of Mr. Wasser’s comments about clients not thinking their offshore team was interesting to talk to because they would not be able to talk about the latest Syracuse game.

“The Syracuse game reference begs the question, as, which is more relevant to innovation? The most up-to-date knowledge of “American Sports”  scene or that last fascinating research article in “Scientific American”? “

There’s a zinger!  I wonder, does too much sports talk at the office negatively impact innovative thinking?  He goes on to say,

“Outsourcing related problems precipitate, & resonate, only because, i find myself in the midst of such circumstances/projects and have to admit, it’s not easy :o )  Perhaps the problems precipitate because, most of my adult-life & all of my all of my important formative & life-experiences are American, and I’ve been an American for a long time.”

Here are still more comments, this time from a colleague in Egypt:

“Very interesting point….especially about the responsibility of the client and the context – knowing importance to improve the performance….

The cultural gap between the client and the resource is an important factor in that. It includes the language, the habits, the business conducting conventions, the ethics, the adopted economical system, and even the time zone differences.

 

I liked very much the point you mentioned about how the client sometimes see the resource. I see sometimes clients filled with arrogance, which leads to a dirty communication channel.

 

I would like here to attract the attention to an important point which causes a global international declining: the bad attributes of the frenzy capitalism (I am not completely neither with socialism nor capitalism) which leads to weak ownership of the worker to the business in addition to weak internal motives and patriotism (in case of same country).

One of the important factors in growing the internal motives and the ethics, is inserting good reference inside the child during all the phases of bringing him up. I see the religious ethics is very important in this context.”

In a followup email he explained that by “weak ownership” he meant that employees needed to think more like business owners and show more passion.  He elaborated on the impact of religious upbringing on business ethics also.

“I mean internal thing like conscience that is built throughout child lifetime. This needs something fixed (not changing with the geography, the time, etc). And the best disciplines to use is the good religious principals that the majority of religions have (specially heaven religions that I know). That internal reference will always tell the body to do whatever good for humans, earth, etc. Will prevent him from doing frauds, not doing his best to do the best. He will act as a mission holder.”

From a US-based person.

“ I’m not sure whether this is a generalization of the “garbage in, garbage out” concept, or if we should just quote that great American philosopher Homer Simpson: “Doh.”"

On a final note, I think I should say that I was surprised at how few of my offshore colleagues got riled up about the article enough to reply back to me with comments.  Frankly, I expected a more passionate response.  Even if they were swamped at work, I would have expected the tone of the article to spark more alarm but it didn’t.  Nobody, it seems, disagreed substantially with the article.

One conclusion seems sure.  Using a globally dispersed team is hard work!

PS:  Even as we add more network bandwidth and add social networking features to electronic collaboration tools, it doesn’t feel like it is getting any easier to use a global team.

 

 

 

What to STOP Doing

I continue to see advice that says essentially that in order to achieve greater levels of success in your career, you have to periodically look at what you do today, prioritize the list, and find a way to actually stop doing whatever are the least important.  (Say drop 15% of the least important parts of your job.)  This is intended to free up additional precious work hours in which you are alert and productive to make time for new activities which are more strategic in nature.  I suppose if your goal is a promotion, you might also look at the new strategic activities as the ones that will differentiate you from your peers.  See What are You Going to STOP Doing? and  The “To Don’t List” ? if you’ve not read them already.

Most recently, I came across a post on the Harvard Business Review by Dorrie Clark entitled, “Five Things You Should Stop Doing in 2012“.  I won’t spoil the article by quoting it all here but one suggestion was to intentionally slow down how often your email inbox is refreshed and to only check emails periodically, say no more than once every 90 minutes.  Constantly refreshing your inbox is a “variable interval reinforcement schedule” which is basically a “slot machine for your brain,”  she warns.

Another piece I recommend is Two Lists You Should Look at Every Morning by Peter Bregman, also a Harvard Business Review blog post.  List #1 is your “focus list” where you want to focus your time.  List #2 is your “ignore list” of the things you predict could distract you from things more important.  I found it really interesting he advocated the discipline of looking at your likely distractions every day before you got into the heat of battle in the office.

I was reminded just today by Dan Rockwell, also known as the “Leadership Freak” that it takes some professional courage to drop things from your list.  He has some great points and great quotes in his post Finding Courage.

“Courage is not simply one of the virtues, but the form of every virtue at the testing point,” C. S. Lewis.

 

The testing point of leadership is courageous letting go.

 

What you let go, determines your potential. Stop pouring yourself out for things that don’t matter. Letting go begins by challenging the status quo.

I really want to embrace the ideas above this year.  I’m not there yet but I’m working on it.  I have gotten to the point, I now regularly find myself evaluating more tasks and asking myself how important or useful they really are.

How Do You Describe Your Cloud Options?

I was looking for some cloud information on my hard drive yesterday and ran across a PowerPoint someone shared with me from 1.5 – 2 years ago talking about public vs. private vs. hybrid cloud options. It then jumped out at me that I’d just seen a Tweet from J. Craig Lowery (also known as @DrJCL on Twitter) on how outdated those terms had become.  See his post Public/Private Cloud? Not really… for an excellent discussion on a better way to describe your cloud options.  To avoid ambiguity, he recommends talking about these four attributes:

  1. Proximity – Is it on or off premises?
  2. Ownership - Does the user own it, or do they pay for it as a service?
  3. Management – Does the user manage it, or pay someone else to do so?
  4. Tenancy - Does the user share it with others, or have it to themselves?

Amazing User Interfaces of the Future?

In an earlier post entitled Amazing Vision of the Near Future, I linked to an amazing futurist video from Corning that predicts many types of computer user interfaces that conform to the shape of objects we are all familiar with.   This post points out some other amazing visions about the future of human-computer interaction.

In this video from a TEDTalk, Pranav Mistry of the MIT Media Lab demonstrates several tools that help the physical world interact with the world of data.

Its hard to believe, this video dates back to November 2009, not quite 2.5 years ago.

Here’s another by John Underkoffler, also of MIT.

Believe it or not, this video dates from February 2010 so this isn’t brand new either at over one year old.  I can’t wait for user interface technologies like these to become mainstream!  I am curious if any of my readers see some real business applications in these approaches.

“Server Chick” for Straight Talk on Server Benchmarking

I saw a familiar face on my employer’s intranet home page this morning. It was Elisabeth Stahl from a project long ago (1994-95) in Akron, Ohio where we built a customer service call center application together back in the heyday of client/server and when object-oriented programming was a radical new concept. As I remember, that application was built using VisualAge Smalltalk running on OS/2 and Elisabeth created our database schema on DB2.  We had computer telephony integration with Call Coordinator too!

Now Elisabeth is Chief Technical Strategist and an Executive IT Specialist with IBM Systems and Technology Group. She’s been working in systems performance for over 25 years and authors the benchmarkingblog.  She’s obviously doing a great job as one of her more influential industry pundit readers says she is a “server chick.”  If you want the straight scoop on benchmarks comparing server performance, I highly recommend  you check the benchmarkingblog and articles such as The Performance Estimate Low Down and Performance in a Flash: New IBM XIV SSD Caching.

The “To Don’t List” ?

This is related to an earlier post, What are You Going to STOP Doing?

I found a couple of interesting leadership-related posts related to the idea of being focused on fewer things and doing a few things well vs. spreading yourself too thin.

First I found How to say No . . . especially to things you want to do on Daniel Pink’s blog where he makes an interesting comparison between having too much information and too many choices begging for our attention to overeating because calories have become abundant and cheap.  Its interesting reading.  Take a look.

Daniel Pink’s post pointed me at a thought provoking video by the famous Tom Peters, author of such famous business books as In Search of Excellence: Lessons from America’s Best-Run Companies.  Peters says that having a good “to don’t list” could be as important if not more important than a “to do list.”  “If you accomplish one really big thing in a year,” he advises, “you’ve had a great year!”  Here’s that video.

Courageous Project Leadership

I was poking around on Bill Smillie’s Finding the Right Question blog and found a great read entitled “How Can We Learn To Be Courageous Project Leaders?”  Its worth reading to help all of us think ahead and prepare for the next project situation that will test our professional and personal courage.

While you are there at Bill’s blog, check out what I think is a related topic, “What is your moral compass for navigating corporate life?” also.

WebSphere eXtreme Scale, a Cool Product You’ve Never Heard of

On my last project, I had the good fortune to learn a little about a product I previously had not even heard of, IBM WebSphere eXtreme Scale.  Its an “edge” server that provides high-performance, high availability caching.

Conceptually, I think of it as a big Java HashMap full of key-value pairs.  The most important difference is that it runs on a server cluster for high performance and high availability. (update) Special thanks to John of the John’s Random Musings blog for pointing out this clustering mechanism is similar to but not quite the same as the usual WebSphere Application Server clustering. (See his detailed comment below.)

We were building web services that would be used by a browser-based point of sale application for the sale of both products and services.  The transactions were relatively complicated, often covering a sequence of user screens.  Customer information was often duplicated at the top of several screens.  Parts and service line items appeared on many screens.

We had two categories of cached information. First, there was information that belonged to a single user’s web session such as the specific work order the store employee was working on with a customer.  Second, there was information that was shared across many user sessions such as equipment manufacturer, model year, model, etc. This was used to populate the first three levels of drill-down information used to look up parts compatible with the customer’s equipment.

You can set up policies to force data in the cache to expire and be refreshed.  We usually set our expiration policy to 12 hours so data would refresh at least twice a day.

Be aware that IBM WebSphere eXtreme Scale does not provide a magic solution to out-of-date information in the cache.  If there is more than one system that might update customer information, for example, you still have to provide your own mechanism to tell eXtreme Scale to purge the object from its cache to prevent a user session from pulling a stale object from the cache.

Also be aware eXtreme Scale does not come with a general purpose explorer tool to view the contents of the cache for debugging purposes.

If you have difficult performance requirement driving you to cache frequently used information and you’re working in the J2EE space, you should seriously consider WebSphere eXtreme Scale.

Essential Skills and Characteristics of an IT Architect

What are the essential skills of an IT architect?  I’ve spent a lot of time over the years thinking about this topic.  Usually, it comes to mind when I’m exposed to someone a project, in a meeting, or at a conference that makes me take notice and think, “I could learn a lot from this person!”   It also comes up often when I’m mentoring a junior person about their career.  I might get asked, for example, “Should I become an architect or a project manager?”

The Open Group Certified Architect Program has this to say about the “Characteristics of the IT Architect”.  Effective IT Architects typically possess and exhibit the following:

Skills and experience producing architectures – IT Architects develop architectures; the definition of the structures of an IT solution to a business problem. In order to accomplish this they must be proficient at the techniques that go into the formulation of architectures, including requirements discovery and analysis, application of abstraction, formulation of solution context, solution alternatives identification and assessment, technology selection, and architectural configuration.

Appropriate technical skills and experience, including technical breadth – IT Architects require practical skills and experience with many application and infrastructure (operational) products, technologies, and services. While often relying on professionals with specialized skills for the construction, implementation, and operational aspects of solution delivery in many of these areas, the IT Architect must have enough skills and experience across them to be able to successfully architect appropriate solutions of heterogeneous components.  Beyond that base of technical breadth, effective IT Architects usually possess additional architectural skills in one or more disciplines.

Disciplined, method-driven execution – The IT Architect uses formal methods to guide and drive the development of solutions, the management of their work, and the production of their deliverables.

Full lifecycle experience – In the development of architectures that address business problems, the IT Architect’s work is primarily performed at the front end of the solution lifecycle. Full lifecycle experience – in particular, the knowledge and appreciation of the construction, implementation, and management aspects of the solution lifecycle – enables the IT Architect to produce solution designs that are truly viable and that can be successfully constructed, implemented, operated, and managed.

Leadership – The effective IT Architect is a leader, providing knowledge, technical, and team leadership skills in their work, to their clients, and for their teams.

Strong personal and professional skills – The IT Architect must have a high level of communications, consulting, and client relationship skills. The IT Architect must be able to clearly communicate complex technical and business concepts, both to clients (internal or external) and to team members, and to negotiate change. Problem-solving of client business and technical issues is a principle role of the IT Architect, and he or she must be capable of effectively identifying and framing problems, leading the collection of elements of information, and integrating this information to produce timely and thoughtful decisions.

Here are a few of my thoughts.  A good IT Architect is someone that can:

  • use abstraction to show key concepts in a simplified form,
  • draw pictures to communicate concepts reasonably well .. and do it while people are watching,
  • model business concepts and technical designs using a real modeling tool
  • name well (see The Art of Picking Great Names),
  • read an audience and adjust their personal communication style accordingly,
  • read an audience and gauge how receptive they are to various levels of solution detail,
  • articulate key ideas to the technical specialists who will implement a solution,
  • articulate key ideas to non-technical decision makers,
  • serve as a translator between the language and needs of business stakeholders and the precise requirements needed by the technical community to make implementation decisions,
  • sell themselves as credible experts,
  • sell their ideas to decision makers to get the funding so that at least some of their ideas become reality,
  • lead thru influence rather than brute application of rank and authority,
  • build consensus thru a well phrased question (See also Asking Great Questions as a Way to Get Noticed in Your Career), and
  • make plausible assumptions and make progress on an idea with limited hard data.

I found this interesting perspective attributed to Grady Booch that I also like.  The architect “along with the project manager, serve as the public persona of the project.”

I’d love to know what you think.