Showing posts with label Enterprise Architects. Show all posts
Showing posts with label Enterprise Architects. Show all posts

Thursday, November 17, 2016

Recent Q&A on Enterprise Architecture

Here are my recent responses to questions on Enterprise Architecture asked by fellow EA's on Quora. Do keep the questions coming. I will try and respond here or on Quora or Linkedin Pulse. 


Saturday, September 14, 2013

Book Review: Quiet and musing on Introvert and extrovert Enterprise Architects

I happened to come across Susan Cain’s bestseller, Quiet: The Power of Introverts in a World That Can't Stop Talking,  mentioned in an online blog debating personality of technologist and Enterprise Architects and decided to check it out. Peppered with anecdotes and stories, the book well researched and highly readable, not in the style of usual self-help books.   It is certainly an interesting book that takes a 360 degree view of introverts, extroverts and their interactions.  (my Amazon Review)

The book starts by exploring the extrovert culture in America.  The reason for the book’s bestseller status is obvious. It speaks to many of us who might have been called “shy,” “reserved” or at times “introverted” and “quite.” Nobody wants to be labeled thus, especially in professional circles where it can spell “failure.”
At work and in professional engagements, speaking up is seen as a virtue, and an opportunity to stand out.  By not doing so, one could miss out on opportunities; or so it is perceived by most of us. In  our professional life, many of us who might prefer the solitude and quite reflection might put on an extrovert façade.

 Just as the label is contextual and not permanent, there are aspects of the book that one may relate to more than others. As the author and most analysts of human behavior have noted, there is a sliding scale of being extroverts and introverts with a vast majority of us finding a place somewhere in the middle, most of the time.

I love the section on Soft Power explaining the Asian-Americans and the extrovert ideal. It highlights the cultural variances as it pertains to extrovert ideal and introverts while also bringing in the cross-cultural dimensions.  The author’s research is based on review of Asian Americans and Chinese American “kids” in America. She summarizes “Though Eastern relationship-honoring is admirable and beautiful, so is Western respect for individual freedom, self-expression and personal destiny.  The point is not that one is superior to the other, but profound difference in cultural values has a powerful impact on the personal styles favored by each culture. In the West, we subscribe to the Extrovert Ideal, while in much of Asia (at least before the westernization of past several decades), silence is golden. “

Musing on Enterprise Architects and personality types:
  • Communication skills, both verbal and written along with an ability to listen attentively is a key success factor. Introverts need to trust their gut and share their ideas as powerfully as they can.
  •  It is typical to see an EA team with all personality traits; would be too much of a group-think if it were otherwise. Susan Cain explains there is a place for both extroverts and introverts in corporate world (If you are in the backyard sitting under a tree while everyone else is clicking glasses on the patio, you’re more likely to have an apple fall on your head.).
  • Enterprise Architects should train themselves to be both introvert and extrovert as the communication scenario demands.
  • Attitude matters more than personality types. By attitude, I mean perseverance and willingness to stick one’s neck out if the situation demands. Willingness to speak up when something is not right is perhaps as important as the right way to say it; and finding right forum where voicing an opinion will matter.
  • If you’re a manager responsible for Enterprise Architecture, a tip from Susan Cain “remember that one third to one half of your workforce is probably introverted, whether they appear that way or not. … make the most of introverts’ strengths – these are the people who can help you think deeply, strategize, solve complex problems and spot canaries in your coal mine
Bottomline: Personality type plays a lesser role in most business interactions than we give it credit. With the right experience, grounding and training all personality types – introverts, extroverts and those in between –can make good architects.

Tags: Books

Friday, July 20, 2012

Ongoing BYOD Watch

Technology leaders regularly scan the landscape for trends in the marketplace, seeking clues on emerging trends. Gazing the proverbial crystal ball and divining insights continues to be an art, more than a precise science. Not many industry watchers, technologists and even tech consumers could have realized game-changing influence of iDevices – iPhones and iPads that has impacted our views on usability of computing and wireless technology in a matter of years.


A couple of weeks ago I posted on Enterprise Architects and BYOD Watch and I continue musing on the topic especially as there continues to be a lot of noise and chatter among digirati on the fate of beloved corporate tools – Blackberries and laptops. For CIO’s technologists and Enterprise Architects, the market trajectory of Research in Motion (Blackberry), Microsoft, Google et al will have a strong ripple effect.

A quick extract from Finance.Yahoo from this morning (20th July) paints an interesting view from a tech investor perspective.

If a picture is worth a thousand words, the graph above tells a story, which I am not going to narrate. Industry watchers and analysts however continue to have a field day exploring multiple dimensions:
  • Lost opportunity angle: Almost identical articles on Nokia and Microsoft’s lost opportunity in in smartphones and tablets appeared in popular media recently. Wall Street Journal : Nokia's Bad Call on Smartphones. Vanityfair on “Microsoft’s Downfall: Inside the Executive E-mails and Cannibalistic Culture That Felled a Tech Giant.” My two cents: The articles make for an interesting read thogh there are not many lessons to be learnt. This is similar to comparing success of Facebook to the pitfalls of most other social networking sites: it is not like a single factor stands out but a series of events. 
  • Worst case scenario planning: What if ABC-Tech goes bust? Corporate leaders and technologists have begun contingency planning for shakeup in the mobile device space. Refer to regular articles in media that seems to love scoops like XYZ &Co drops Blackberry (re: Qantas decides to drop RIM's BlackBerry news from this morning). These prompt boards and c-level executives to ask their technologies to ask about their firm’s contingency plan.
It's friday afternoon and I must get back to gazing my crystal ball.


Friday, June 29, 2012

Enterprise Architects and BYOD Watch

It has been a really interesting past few weeks in the mobile world, and to watchers of Bring your own Device (BYOD) the trends spell interesting challenges and opportunities.

A lot has been happening in the smartphones world - iPhone 4S is continues to gain popularity, increasingly price-competitive Android smartphones, improving Windows smartphones are enticing consumers. And iPad continues to be the tablet of choice for consumers. Though I am hesitant to use clichés, I think we are at a strategic inflexion point in mobile computing and BYOD. Perhaps the began in 2007-08 when the Apple iWave began upending Blackberry as the de-facto device for mobile workers. iDevices helped consumers visualize how smartphones could help mobile workers do a lot more than just read emails-on-the-go.
A few interesting happenings just in the past couple of weeks are worth analyzing in greater depth (beyond a blog like this):

  • Microsoft announcing Surface is trying to bring tablets to information workers traditionally used to working at their desk using PC’s and laptops. It promises users “Create, collaborate, and get stuff done with Office. Explore your world with fast, fluid Windows 8 apps”
  • Google’s announcement of Nexus 7 tablet yet another push by the tech giant to extend into social media and hardware
While the two tow tech giants make moves extending their reach in the hardware space, Research in Motion (RIM), maker of blackberry announces a delay in launch of BlackBerry 10 mobile OS (and other financial challenges the company is facing)

What does this mean to us? While the employee-and-tech-consumer in us wants a broader, faster corporate push towards BYOD, the Enterprise Architects are going to try and address the ROI and TCO questions around such a moves.
Several recent reports are pointing to BYOD and how it is pushing up IT costs. The question to be weighted: Is whether the increase from BYOD just another cost of doing business or a cost of convenience?!

Friday, November 18, 2011

Enterprise Architect : shifting from consulting to Full-time EA (and back)

For the past few years, I have been a consulting Enterprise Architect,  working with a wide cross-section of clients, industry verticals and technology domains. Some of my engagements have been short and specific to an EA domain. I have also had the opportunity of being embedded in client’s EA organizations for extended periods of time. Some of my offline with  client and consulting EA's sometimes shifts to career planning and management.  Many in full-time Enterprise Architect roles at large enterprises muse on moving to consulting; I have seen more than a few join my EA practice during recent times. Likewise, I have also seen fellow consultants take up full-time EA role at client enterprises.  

A few common themes for such shift include personal reasons constraints - need to cut back on travel consulting involves - or the urge to move on to other industry verticals which consulting gig’s can facilitate. And in many cases it also boils down to the bottomline ($$$).  Some random observations based on experiences of people I have seen switch roles
Full-Time Enterprise Architects
Enterprise Architect Consultants
The role of an Enterprise Architect is typically a mix of subject matter expert, internal consultant, mentor and coach.
Role of a consulting EA is that of a deep subject matter expert, focused on advising client’s decision making.
As key stakeholders bridging the business-IT divide, Enterprise Architects are vested in the success of strategic initiatives, held accountable for their decisions and advise given to business and IT.
Consulting architects are not expected to have a 'permanent' tenure with a client. While they may also be responsible to deliver in success of client’s initiatives, they are generally not held accountable
Vendor relationship and management skills are getting to be important, especially in large-scale sourcing contexts.
The focus is on client stakeholder management and ability to continually sell one’s individual and consulting firm’s services
As client’s technology teams get leaner with larger sourcing initiatives, Enterprise Architects are expected to add to project/ program governance and also governance around vendor management
EA consultants may sometimes get an opportunity to be a part of client's Architecture governance teams but the focus is primarily on solution delivery and reviews
An Enterprise Architect’s performance indicator, measure of success includes contributing to long-term growth and ensuring success of business’ initiatives
Consultant’s PI is more black-and-white and typically includes a mix of billable utilization, meeting sales targets, contributing to consulting firms’ downstream business
An EA can reach out to internal networks and resources not available to outsiders
The consulting EA may need to be facilitated on reaching out to internal - client - resources. however he will have access to his extended network from his firm
 
The above is by no means a comprehensive list though it may weigh in while one considers a switch from being a consulting EA to a full-time EA. Do ping with your inputs and I will add to it.

ps: Added note from a fellow EA (Kurt Barndt)  "I would add you serve who ever pays you.  If you work for a services organization sometimes you are put in the position to balance your company’s interests with that of your client(s).  Working in house has an easier alignment from a company perspective however organizational/peer alignments become more significant especially as there are less and less in-house employees in the ever growing services-based environment."

Wednesday, August 31, 2011

Musing on accidental Enterprise Architects and Enterprise Solutions Architect

Enterprise Architects (EA's) periodically like to muse on the evolution of their roles and how they need to be aligned more with the "Business." Some get on discussion forums to debate how they/their roles need to move up the value chain, which makes for an interesting blog post but practical challenges continue to keep many EA's grounded.

Last week I was visiting clients in Washington DC area and met with their EA's whose business card reads "Enterprise Solution Architect". It was in the context of their adoption of TOGAF and ideation on how they could leverage the toolkit and frameworks better. This was a group of technologists and business analysts who had grown into the EA roles in their organization, a mid-size enterprise.

During our discussion, some were voicing concerns on the strategic-vs-tactical challenge of their roles. I got a feeling that these were accidental Enterprise Architects. For some the goal was to be the Über techie, a.k.a lead technical architect, focus on technical problems with projects and programs than on other core EA challenges within the enterprise.

Of late, I see a lot more accidental EA’s wanting to move towards their Business or Solution Architect roots (circled in image above). And in many cases, organizations are also providing the nudge. Organizations that employ experienced technologists in "Enterprise Architect" roles want them to double up by wearing technical or business analyst hats in projects and programs. In TOGAF speak; the focus of Solution Architects is on B. C. and D. dimensions. (refer image).
I guess there is some rationale here: in a tough economy, employers and managers are looking for a better ROI on their employee’s skills. Remember, Enterprise Architects are highly paid "resources" and productivity of resources is a key performance indicator.

Maybe it is just me, but in an uncertain economic climate, I see a lot more Enterprise Architects hunkering down to leverage their core competencies – technical or business skills – than stepping up to prepare their firms for growth.


TOGAF: The Open Group Architecture Framework


Tuesday, August 9, 2011

Viewpoint on Enterprise Architecture Consulting: Architecture Assessments and Roadmaps

My team is wrapping up an eCommerce assessment and Foundational Stability engagement for a client and I have been reviewing some of the older program documents. A few of these documents date back about five years ago – authored at the time of program inception – provide an excellent rear-view mirror. One in particular titled "eCommerce Strategy current assessment"is especially thought provoking. It was a report authored by EA consultants from a competing firm, highlighting the application portfolio with inputs from Technologists and Business stakeholders. The deck had a whole set of documents one would expect including

• eCommerce Capability Models, Capability Mappings
• Analysis of Business Units including Heat Maps
• Application Assessment catalogs
• Survey administration approach, toolkit and findings including highlights from technical and functional standpoint
• Benchmark surveys from other client engagements
• Health-Check and findings
• Future State Roadmap

The client is about five years into the enterprise eCommerce consolidation journey, with several projects and programs executed (read, millions of dollars spent) and my team was engaged to assess the Architecture developed and rolled out based on the original roadmap, a checkpoint if you will.

The report by itself was comprehensive, what you would expect from a tier-one consulting firm and would have probably cost a small pile of money to compile. Needless to say a tremendous amount of time and effort from the organization’s resources also went into that excercise.

The fact of the matter is that the benefits of portfolio consolidation promised by the strategic exercise are far from realized. After reviewing the report and documenting my observations on the small steps the organization had taken towards actually developing a unified enterprise "eCommerce Platform," I began to reflect on the challenges of laying a roadmap versus the effort involved in actually realizing it. The portfolio of eCommerce platforms remains fragmented with redundant applications meting their individual functional requirements in a silo. In some cases the portfolio is more fragmented than it was five years ago. For instance, the report talks about 25 Order Creation Applications, 11 applications supporting product search and over 8 reporting applications. Fast forward five years and the numbers have not changed! The TCO gains from consolidation have not been achieved. The only saving grace: the organization has been Offshoring a lot more of application development and support, thereby reducing overall IT cost.

As a consulting EA, I get to visit a fair share of clients, some of them a while after my teams have helped assess landscapes, define roadmaps or strategies for future. The sense Déjà vu during such reviews – similar to the experience in the current engagement - should not surprise the seasoned consultant in me, but it still does.

Other intersting views on EA this week. An interesting Video on Enterprise Architecture (Tipoff Mike Walker's Blog) - What is Enterprise Architecture According to Industry Thought Leaders

Wednesday, August 3, 2011

Enterprise Architects and Social Media

Most of us who started our digital lives with Web 1.0 or before are well past the novelty of yet another social media tool. You perhaps remember the buzz in the mid-nineties over the novelty of signing up for new and newer free-email services before yahoo, hotmail and gmail became the gold standard, with unlimited .. or near unlimited mail achieves? We seem to be going through a web 2.0 version of the same with trying to rearrange our circle of friends on GooglePlus (re: WSJ article on “How to Circle Your Friends Without Alienating People”).

While this buzz is enough to get the stock and IPO valuations of dot.com’s going through the roof, the Enterprise Architect in me has been trying to reflect on what this means to those of us in the corporate world. Among the few dimensions that requires deliberation and analysis

  • Guiding your organization on proliferation of social media tools. This includes guiding business leaders, corporate marketing folks and other stakeholders with a viewpoint emerging tools platform and whether they are aligned with corporate business and IT strategy

  • Guiding corporate policies and governance around tools. We see extremes on social media policies in the corporate world. A few organizations block any employee access to social media tools and websites while others allow complete unfiltered access. Many, however take a middle ground (eg. Allowing access to linkedin but not facebook or adverts from streaming in). In most cases, organizations also reserve the right to monitor and log activities of employees.

  • Participating and enhancing knowledge network. Many EA’s from Service organizations and end client organizations actively participate in online discussion forums, blogs and try and leverage the tools. Few organizations also encourage internal communities of practice to go outside (e.g corporate blog on Microsoft or Oracle technologies by Infosys’ bloggers)

  • Organizational branding: while organizational branding has been a traditional area of focus when it comes to digital marketing strategies, online reputation management is an emerging area of interest to business leaders. Views on products and services can be made and weighed in on by digirati in a matter of hours if not days or weeks, and it requires an equally fast and deliberate response to defend one’s reputation.

Enterprise Architects who operate at the intersection of business and technology have a unique opportunity to bridge the gap when it comes to evaluating emerging technologies and their applicability in their business contexts. Working with their business stakeholders to visualize newer application of technologies is just one of the tasks at hand.


A few interesting blogs and viewpoints on the topic:


Sunday, July 17, 2011

Enterprise Architects Enabling Strategic Global Sourcing

As the lead Architect for my firm at the client we are engaged with, I anchor a weekly pow-wow between our teams and client’s Enterprise Architects. The agenda for the sessions is open, addressing key architectural, technical and process related issues, ideation on best practices and discussions from our respective eco-systems.

During a recent session, Dave, one of the clients EA’s brought up the topic of sourcing and a viewpoint he was building for his CIO. I pointed out to Dave how the sourcing challenge EA’s at this firm are coming to grips with are not unique. I pointed him to my Cutter Journal paper on the topic (Enterprise Architects Enabling Strategic Global Sourcing) and we began brainstorming some of the ideas as it was applicable in the current context.

After the brainstorm I began musing how I hadn’t revisited my views after I had written the paper, over a year and half ago. A few of the background issues continue to plague Enterprise Architecture groups: sluggish economy and lack of hiring means Enterprise Architecture groups are not getting fresh talent. Lack of hiring at the bottom is also impacting nurturing of homegrown talent in client organizations while continued visa restrictions also means Offshoring firms are discerning when it comes to bringing talent more than needed onsite.

I had addressed some of the key issues I had seen at client organizations in the paper:


  • Loss of technical expertise due to sourcing

  • The need to coordinate multivendor scenarios

  • Vendors lacking knowledge of organizational dynamics

  • Vendors lacking specific business context

  • Vendors not up to date on organizational processes, acronyms, and jargon

Since I wrote the paper, I have continued to be engaged with other clients and Enterprise Architects, who continually voice views on similar challenges I had highlighted in the paper. As I continue to brainstorm on the topic, I might revisit the views in the paper. Do send in your comments too.

Sunday, July 10, 2011

Do Consulting Enterprise Architects provide value and meet the expectations of organisations?

There is a fascinating conversation thread in the Enterprise Architecture forum on Linkedin. It started with Michael asking "Do the consultancies (including Gartner, KPMG, DeLoitte, ...) actually meet the expectations of organisations or is there a gap between the value they claim to add and what they deliver?"


The answers are varied: those on the sell side (respondents from sourcing firms) are weighing in to say they do provide value while those on the buy side are musing on the real value. The question is all the more important given the current state of stagnant growth and sluggish growth in economy. One can perhaps look for answers in two section of the market



  • The heating up of tech hiring in Silicon Valley. The recent dot.com IPO’s are certainly adding to the buzz in the e-commerce world.



  • Hiring by technology outsourcing firms. With a slow but steady growth in outsourcing, technology consulting and sourcing firms continue to add to local jobs (though evidence on this count is purely empirical)


The role and job description of Enterprise Architect at these two ends of the technology spectrum are as distinct as their areas of focus. Silicon Valley technology firms, fueled by venture capital funding and IPO dreams focus on cutting edge solutions and adoption of emerging technologies and tools. EA’s here are really hands-on Über techies, tech leads and solution managers rolled into one. On the other hand Outsourcing firms focus on providing technology services and solutions – not always cutting edge solutions – to businesses and enterprises focused on automation of processes and deriving ROI from their existing investments. Here, the role of EA may be a bit more text-bookish: integrating business, data, information and technology architectures to meet strategic goals.



Back to Michael’s linkedIn question: the role of a consultant, or in this case a consulting enterprise architect would depend on the nature of problem s/he is hired to consult on. In the silicon-valley-firm example, the EA-hired-gun would probably be staff-augmenting the already sharp technologists. “Meeting the expectations” here would mean helping develop and take solutions to market at the speed in which the dot.com client needs it to be done.


On the other hand, EA-consultants in Corporate-America, typical clients of consulting firms, focus on bringing their breadth of consulting and problem solving experience to weigh in on the challenge being faced by the client. Lots of times such consulting is about the ability to quickly identify the problem and applying a solution pattern. The solution patterns could be custom-solutions or the ones the consultant or his firm has seen successfully applied to solve similar problems for other clients. "Meeting (or exceeding) the expectations" in this instance is dependent on quickly identifying the root cause of the problem and being able to generate consensus on the problem statement with distinct groups of client stakeholders: including the hiring manger and his other internal stakeholders. If the problem statement is wrong or wrongly identified, the solution will obviously fail.

In my years in consulting, I have worked with some sharp and business savvy Enterprise Architects and IT executives who are open to out-of-box thinking and solutions. I have also encountered a fair share of executives who engage external conlustants to validate their own thinking while strongly holding on to their NIH views. You don’t need a consultant to tell you who benefitted from my engagements. :-)





A few interesting links


Thursday, June 23, 2011

Case Study: Learning to KISS eCommerce design?

More than a decade after the dot.com bust, we seem to be witnessing another version of an eCommerce boom, a 2.0 if you will. While rest of the economy continues to lag, the success of Linkedin, Pandora and other internet IPO's this summer is getting business and IT leaders excited about eCommerce strategies and implementations.

One can argue that the success of dot.com 2.0 startups is more due to innovative business models than a radical innovation in technology. The tools and technologies for web development have matured, and so has eCommerce development life cycle. The proliferation of web technologies and tools, along with maturing industry also means one is likely to see the usual clutter of incompatible tools and technologies, version incompatibility, challenges with back-end integration.

For a consulting Enterprise Architect like me, the challenges translate to opportunities (there is demand for good eCommerce Systems Integrators and Architects!) In my day job, I have been consulting with a client on eCommerce program governance, roadmap definition, alignment with the corporate Enterprise Architecture blueprints. It is not all strategy work there is the roll-your-sleeves solution delivery: helping teams’ firefight rollout of functional and technical enhancements. My observations on eCommerce Enterprise Architecture - not in a particular order - follows.

The Program: eCommerce implementation for a large (Fortune 500) firm headquartered in Ohio. The company is focused on Supply Chain management for a specific business vertical. The current phases of eCommerce platform are focused on enabling Business-to-Business (B2B) integration though the architecture roadmap includes evolving towards B2C too.

Organizational IT: Federated, shared services model. The eCommerce strategy and applications are owned by a senior executive (technology solutions owner). Integration - including SOA, J2EE services - is a shared service. Configuration Management is owned by another organization as are Database and systems administration and Quality Control/Assurance. Needless to say backend systems (SAP et al) are owned by other LOBs. The company's Enterprise Architects are similarly verticalized, with a couple of them aligned to eCommerce programs and one focused on integration. The eCommerce Architecture is a "next generation" solution intended to upgrade the "legacy" web application and expected to evolve into the front end for most of the lines of business.

Architecture: The eCommerce Architecture is based on an IBM centric web-commerce stack : IBM's Portal, Commerce and Web Content Manager products integrated by Java. DB2 is the Commerce data repository while solution from Endeca is leveraged for product feeds and search. Java is also leveraged to develop web services and real-time integration with back-end order processing, fulfilment and pricing systems of which there are more than a few including SAP based and homegrown solutions; typical of fortune 500 organizations.
Most of the design and development of the eCommerce platform is sourced to vendors. Sometime ago, the client wanted to move away from Vendor A; in stepped my employer. I got engaged during the vendor transition phase: a fascinating opportunity for a consulting Architect. After a successful vendor transition, I lead the team through a critical project that helped them find their way around intricacies of the client’s IT shop. Observations from the trenches include:


  • Division of labor being taken to an extreme: There is a specialization of skills, even within a single vendor’s stack. Most of the younger generation developers - read those with about 3-6 years experience - are content to hone their skills in a specific toolkit, be it Websphere Commerce, Websphere Portal or WCM. Few developers seem to have the aptitude or inclination to span the technology stack, even within a vendor’s platform, which is a problem and an opportunity: It is a problem most large eCommerce programs are plagued with, and an opportunity for astute developers to scale up and become uber application integrators.

  • Remote development. Offshore service providers, including my employer, are taking on larger Systems Integration programs. And although offshoring IT services has got commoditized, almost every large program seems to go through similar learnings. Onboarding and enabling right skills is part of the challenge, exacerbated by the division of labor. Having a Business Analyst and Technical lead sitting in Anytown, USA guiding a portal developer sitting in Bangalore, and commerce guy in Mysore can be challenging at best; made worse when the portal developer does not understanding squak of the underlying commerce services or database.

  • We are yet to realize the promise of plug and play. There is a proliferation of tools and technologies and most don’t plug-and-play without a lot of plumbing. Many products within the same vendor’s architecture also require additional time and effort in “integration”

  • Services? For most part, the promise of SoA is yet to be realized. Period.

  • Complexities of build and deployment

  • And then there is the backend….. Most eCommerce systems are intended to enable a web front-end to enable customer self-service. Internet is ‘yet another’ channel for back-end systems that can range from legacy mainframes to contemporary but equally complex backend systems.
Back to my day job. I continue to bridge the gap between our techies and the client's Enterprise Architects and technologists. And my team is trying to help fix some of core issues - including the ones highlighted above - in the current landscape that prevent the system from scaling up. I wouldn’t be leading the gig if the ‘Architects’ had kept things simple to begin with.

Bottomline: When it comes to Architecting eCommerce systems, we don’t KISS! Most of us come out of Engineering and IT dreaming of developing simple, elegant and functional solutions to business problems. The new generation of developers architecting eCommerce applications seem to have skipped class when that lesson was being taught.

Saturday, August 21, 2010

Rhetoric vs reality: Global body shops, chop shops and sweat shops

A week after U.S. legislator Charles Schumer called Infosys a “chop shop,” setting off a wave of outrage in India, he clarified that he meant that firms like Infosys are “body shops.” Senator Schumer clarified In the tech industry, these firms are sometimes known as ‘body shops’ and that’s what I should have said.” Having spent much of my working life in the technology services industry across the globe, such statements by politicians don’t really surprise me, but the media in India and America seems to have had its share of fun ‘analyzing the stories. Another related story was that of the hike in fee for US Work Visa (H1 visas). This again lead to interviews with industry gurus who had views and counter views on the impact of the hike. Visas and travel are an integral cost of doing business for offshoring firms. Such cost do go up over a period of time. Again me thinks: So what's the big deal?

In all the rhetoric, the politicians and analysts quoted in the media seem to have forgotten a basic fact: While Indian service firms Infosys, TCS and Wipro pioneered Global Delivery model and offshoring, it is the western and American software service giants including IBM, Accenture, HP and others that have taken to it like ducks to water. I guess most poeple outside the software services industry didn’t realize IBM was among the top public sector employers in India, employing over a hundred thousand people (WSJ: Is Big Blue India’s New Big Boss?)

With Big Blue is getting bigger in India should Senator Schumer go after them too and include IBM in his next speech as a chop shop, body shop, or sweat shop?!

Fact is that the software Services industry, whether co-located in a geography continues to be labor intensive. Automation of software development continues to be the holy grail of Software Engineering though better tools and techniques continue to emerge. Software development and maintenance requires an army of programmers, developers, analysts and managers.

Politics and rhetoric aside, software services industry is more globalized than most analysts and journalists realize. For those of us in the industry however, this is not much of a surprise. Case in point, James McGovern, an Enterprise Architect with a Fortune 500 Insurance firm used to be a rabid outsourcing critic. In the past few blog posts, one can see a much more pragmatic voice on offshoring emerging. (Re: The Secret Relationship between Enterprise Architecture and Outsourcing)

Blogs and Links: