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

Thursday, October 26, 2017

Tech Giants Paying Huge Salaries for Scarce A.I. Talent : Why it matters

An interesting article in New York Times “Tech Giants Are Paying Huge Salaries for Scarce A.I. Talent (link)” is making rounds in social media and among the digirati.  Artificial intelligence has fascinated technologists and science fiction writers for decades, but the business world seems to be getting serious about its disruptive potential. Technologies including Deep Blue from IBM, DeepMind from Google or Microsoft’s Chatbots are going beyond press-mentions, and beginning to demonstrate value in solving real world problems.

A.I. also continues to be on “top 10 or “top 25” Digital Startup ideas. Promising AI and Machine learning focused startups are frequently being courted and acquired by the tech oligopoly — Apple, Amazon, Facebook, Google and Microsoft (link). In many cases, executives see it as an opportunity to on-board a pool of talent more than just acquiring a promising technology.

The author, Cade Metz, after discussion with “nine people who work for major tech companies or have entertained job offers from them,” explains how tech giants are paying “Huge Salaries” for AI Talent. A few key points from the article


  • In the entire world, fewer than 10,000 people have the skills necessary to tackle serious artificial intelligence research  
  • At the top end are executives with experience managing A.I. projects. Anthony Levandowski, a longtime employee who started with Google in 2007, took home over $120 million in incentives before joining Uber last year.
  • Typical A.I. specialists, including both Ph.D.s fresh out of school and people with less education and just a few years of experience, can be paid from $300,000 to $500,000 a year or more in salary and company stock
  • Costs at an A.I. lab called DeepMind, acquired by Google for a reported $650 million in 2014, when it employed about 50 people, illustrates the issue. The lab’s “staff costs” as it expanded to 400 employees totaled $138 million. That comes out to $345,000 an employee.

Some of these are broad generalizations and sound like “in the entire world, fewer than 1,000 researchers are working on the cure for XYZ cancer or ABC disease.” One can discount such hyperbole since the author got most of his inputs and figures from just “nine people.” Still, the premise of the article is still logical and rather straightforward:

“Tech’s biggest companies are placing huge bets on artificial intelligence, banking on things ranging from face-scanning smartphones and conversational coffee-table gadgets to computerized health care and autonomous vehicles. As they chase this future, they are doling out salaries that are startling even in an industry that has never been shy about lavishing a fortune on its top talent.”
Let us look at some of the implications of Why and to Whom this matters:


  • Technology Executives: In a classic case of “Airline Magazine Syndrome,” functional leaders and executives across businesses are beginning to lean on their IS Executives to demonstrate how they leverage Artificial Intelligence, big-data, visualization, robotics and other digitization techniques.  Technology vendors are sensing this opportunity and are cleverly rebranding their CRM, ERP and other products as “AI based,” sometimes by just adding cool-new chatbots to the existing platform. 
    • It is the responsibility of Enterprise Architects and technology leaders to see through the emperor’s clothes. 
    • Technology leaders can use this opportunity to engage and inform their stakeholders, and help them contextualize relevant user-stories and requirements where they will demonstrate value
  • Consulting firms: Consulting firms and System Integrators are jumping the AI bandwagon by adding offerings to ‘Digital Transformations.’  
    • It is necessary for consultants to stay abreast of emerging technologies. However, consultants must also take an objective view of their client’s requirements. While AI holds a lot of promise, in some cases it may just be a solution looking for a problem. 
  • Software Engineers: The article highlights how “companies like Google and Facebook are running classes that aim to teach “deep learning” and related techniques to existing employees.”
    • If you happen to be an engineer selected to learn “deep learning,” great. 
    • Otherwise, you can explore opportunities for self-paced learning on Fast.ai, Deeplearning.ai  etc. Keep in mind a certification or training alone may not suffice if your organization is not embarking on an AI based initiative
  • Startups and entrepreneurs: Many startups and entrepreneurs are looking to carve out a niche in this greenfield space 
    • If you aspire to be acquired by “the tech oligopoly,” you should focus on innovative application of AI and ML. However, this is much harder than it sounds. Such real world applications of practical value are not easy to visualize. 
  • Students of Computer Science: There are several ‘hot’ and emerging technologies competing for our mindshare, though Big Data, Robotics, Automation, AI and ML stand out. 
    • As a student of Computer Science, a specialization in AI and machine learning may help you stand out from the crowd. 
    • A specialization in these technologies will certainly help you land a better job, but don’t be under pipe-dreams of “$300,000 to $500,000” payouts. Those are going to be much harder to come by. 

I’m sure this is not the last word on this topic.



Thanks for reading! Please click on Like, or Share, Tweet and Comment below to continue this conversation | Reposted from my Linkedin Pulse article

Saturday, March 7, 2015

What I learnt in a year running an Architecture Review Board (ARB)

Among my first tasks after joining the Enterprise Architecture team for my employer - a multinational Ag Biz company - was to redefine the Architecture Review Board (ARB), a need that was triggered by a review of our Enterprise Architecture program.



The head of architecture explained the company’s “history” of architecture governance and the shifting focus of the architecture function. As in many large multinational enterprises, the company’s IS team continues to evolve to mirror changing business drivers. The pendulum had swung from extremely governed to the laissez faire model, and I was tasked with operationalizing a fit-for-purpose ARB.

So, what did I learn?

As should be expected of any global organization, the architecture landscape is complex. Running the ARB process gave me a ringside view into changes being introduced into the landscape.

To appreciate the value chain, understand organization change
  • The architecture tradeoffs used to review proposals and the ARB recommendations are a good dipstick into the stakeholders’ appetite for change.
  • The ARB is integrated into the portfolio and program management processes. Hence, ARB members can try and understand Who (stakeholder/sponsor) is paying for the change, and Why (the value expected from the investment)
Appreciate the subtleties of “business” engagement

Passionate debates on engaging with business frequently surface in online Enterprise Architecture forums. Some of it is because the term ‘business engagement’ is nebulous, and may be used to describe several things
  • People – Business user of a business system or process
  • Functions - Business function like Finance, HR, Supply Chain etc, or Business unit - like the British or Turkish subsidiary of a multinational or the “Houston manufacturing plant”
  • Leaders and leadership teams – Ranging from top tier CxO reporting to the CEO/Board to leaders of functional or business units and others in between
During ARB reviews, I sometimes find it easier to just work with the sponsor - people with money or people who know people with money - than to debate how to engage “business”. The assumption is simple: sponsors follow the money.

Aspire for a “seat at the table” but be pragmatic

Engaging business to “define strategies” is another topic of continual debates in Enterprise Architecture forums. In reality, a seat at the table may be more about effective realization of strategy than about ideating on business scenarios in an ivory tower. For example, a few scenarios:
  • M&A: Mergers & Acquisitions are generally strategic business decisions involving a handful of people - the board, CEO, CXO, a business head or two and handpicked lawyers and accountant with sundry advisors.
  • Decision to expand or divest business: Also strategic business decisions involving only a handful of people.
  • Decisions to enter new line of business. E.g a software services company deciding to operate data centers or expand into “cloud operations” or an AgBiz company introducing a complementary solution for farmers
In these scenarios, EA’s and other senior managers may be engaged to enable execution *after* such strategic decisions are taken.

In this article, I try and highlight a few of my empirical observations and learnings. A more detailed discussion of Architecture Review Board and my case study can be found in this month's Cutter IT Journal article (Enabling Successful EA Governance -link).

Cross post from my Linkedin Pulse

Tuesday, November 19, 2013

Book Review : Enterprise Architecture As Strategy

"Enterprise Architecture As Strategy" (Amazon) by Jeanne W. Ross, Peter Weill, David Robertson is perhaps the most quoted book. Online forums on the topic quote this as one of the few really good references on the topic and I agree.

The authors do a great job of introducing and packaging concepts in Enterprise Architecture – operating model, maturity model, core diagrams, IT engagement model  – that are referenced by EA practitioners, consultants and academics alike. The case studies based on academic research of over “200 companies” keeps the narrative grounded.

Who is this book for?
  • Practicing Enterprise Architects and EA consultants will find the topics and case studies refreshing. It certainly got me reflecting on my employer’s target operating model  
  • The book speaks to business executives as much as it does to EA practitioners.  Executives will also find it a handy reference that can equip them to “govern” IT strategies
  • Those looking to get into EA (many IS/Technical Architects, business analysts and process consultants) will find the book a good introduction to EA “big picture” topics; and perhaps an introduction to some consulting jargon

The book is not an EA “cook book” or a “how to” guide. Unfortunately, learning how-to-do-EA will only come with experience and a few grey hair.
 
Tags: review / reviews

Thursday, September 5, 2013

Enterprise Architecture lessons from City Planning: Don’t let the 'Walkie-Talkie' slip by

​“Enterprise architects are practitioners of enterprise architecture; an information technology management discipline that operates within organizations” goes the Wikipedia definition. In a sense, we are practitioners of a unique craft that entails bridging business drivers, goals and vision with technology capabilities and solutions, while ensuring the proposals align with the organization’s roadmaps and regulations. All this can be a bit overwhelming as an elevator pitch. When asked to describe what an Enterprise Architect does, it is common to refer to the “City Planner” analogy. For example, US Government's NIH reference of Enterprise Architects starts by explaining how “You can relate enterprise architecture to the more widely understood concept of city planning. In city planning, zones are established for very specific purposes. The buildings that are built in these zones are constructed to specifications to meet those purposes.”

The EA as City Planners is exactly the analogy I was reflecting on when I came across recent news accounts of the car melting skyscraper in London (“'Walkie-Talkie' skyscraper melts Jaguar car parts”). A few thoughts and perhaps lessons here:

An article quoted the developer of Walkie Talkie building analyzing “the phenomenon is caused by the current elevation of the sun in the sky. It currently lasts for approximately 2 hours per day, with initial modelling suggesting that it will be present for approximately 2-3 weeks.” It is unclear whether the Architect and city planners analyzed this bit of information and decided, the residents of the neighborhood could live with the problem for about 2 hours a day for 2-3 weeks in the year? There is a distinct parallel to the challenges Enterprise Architects face. EA's are sometimes requested to let “tactical” solutions and proposals slip by because the potential impact is “calculated” to be minimal? An example perhaps when the business stakeholder indicated security of data was an “important” Non Functional Requirement (NFR) but got a sticker shock when told what it would cost for the system to be architected with the right principles within our firewalls. The Business stakeholder may also have been sold on a much cheaper alternative: a SaaS solution, hosted on the cloud by a third party vendor. The vendor might have promised that the risk of data breach was “minimal.”

The EA question here: Could the business live with this security risk for "2 hours a day, 2-3 weeks in a year?" Enterprise Architects should review findings of pilots, POC and modeling during initial design; and also stand by the right thing to do!

Another article on the topic mentioned how “The Architect Behind London's Car-Melting Skyscraper Has Had This Problem Before"Rafael Viñoly, the Uruguayan-born architect who designed the new London building that's now frying eggs across the street because of its intense reflection, is the same architect who designed another notorious "fry-scraper" in Las Vegas years ago. In 2010, guests of Viñoly's Vdara Hotel and Spa at MGM's Aria began complaining of severe burns from the glare being reflected off the building's facade."

This is also an issue Enterprise Architects are distinctly familiar with: Governance, feedback loops and of course the courage to say "No" to recurrence of design flaws. And holding a vendor accountable.

Of course, the biggest assumption with the City Planning analogy is that cities are populated by citizen who want to be governed and live by the rules, which would exclude cities in most of the developing world. I crack a smile every time I visualize the city planner analogy applying to Bangalore, the Indian Silicon Valley. On googling, I discovered that the Bangalore Development Authority does have an elegant master plan (link) with a Town Planner Member on board; an Enterprise Architect exists! Per the description, Bangalore’s Plan considers the present situation, the various growth trends at work and future issues. It integrates key influencing factors including City's natural environment, its heritage, and issues of economic efficiency and social equality.” And the visuals on the web page are akin to landscape diagrams Enterprise Architects in a fortune 500 enterprise would be proud of recommending!

My guess is that the town planners in Bangalore, like their peers in most developing nations encounter every imaginable resistance from “stakeholders” - from power hungry politicians who sign off on variances to zoning ordinances, to corrupt planning inspectors and bureaucrats willing to look the other way at major and minor infractions. Of course the City Planners also operate in cities that are populated by residents willing and intent on bending or breaking every zoning rule that doesn’t meet their fancy!

Just like much of the world's population inhabits the third world cities with toothless City Planners, much of Enterprise Architecture is practiced in enterprises without strong governance and stakeholder buy-in. Perhaps Enterprise Architects are really like Bangalore’s Town Planners: defining elegant master plans, landscapes and roadmaps from an ivory tower while their peers rubber-stamp every variance to the standard that “stakeholders” demand!

Other popular EA City Panning references
  • Enterprise architects are like city planners, providing the roadmaps and regulations that a city uses to manage its growth and provide services to its citizens. Wikipedia
  • Companies are focusing on "building codes" that define the principles and guidelines for architecture and on "building permits" that are granted to change initiatives that have been deemed compliant through the architecture review process. City Planning: A Metaphor for Enterprise Architecture: CIO.com
  • A Simple and Flexible Specification Enterprise Architecture Practice - CMU Reference

Sunday, July 28, 2013

Musing on Agribusiness, Modern Agriculture and Enterprise Architecture

Friends, peers and former colleagues occasionally ask me what I do for a living and when I say Enterprise Architect, they raise they eyebrows. And when I say an EA for a multinational agribusiness firm, eyes begin to glaze over.
My journey into the complex and fascinating business of modern agriculture started a little more than a year-and-half ago when I took on a role of Enterprise Architect with a multinational Agribusiness company. In my previous consultant roles, I was well aware of the intricacies of EA, trained and certified in one of the popular methodologies used in the industry (TOGAF). In a sense, I had a broad understanding of the practice and application of EA. I was, however, removed from the intricacies of the business of my employer, agribusiness.

Learning about the “business” is critical for Enterprise Architects given the role we play in bridging the IT-business divide. It also helps that my employer prods employees to gain insights on our business of Modern Agriculture. One such recent program was the campaign to complete the Masters of Modern Agriculture through CLA, which prompted me to reflect on my journey thus far.

As is to be expected, many executives and business and functional leaders here have a farming or agriculture background. One could argue many of us – even urbane city dwellers - are not too far removed from agriculture perhaps with just one or two degrees of separation from agriculture.

Think of farmers and farming and one might visualize the quaint old man in a turban in a paddy field in India or the frail farmer tilling a dry plot of land in sub-Saharan Africa or the tall guy in wrangler jeans and cowboy hat standing next to a lush corn field somewhere in Iowa or Mid-western United States. Though I grew up an urban kid, and mostly lived in larger metros in India, my link to agriculture in childhood began when we would visit my dad’s ancestral town in Tamil Nadu for summer vacations, a trip that would include trek to the lush paddy fields that his brother and extended family managed. Family discussions during such get-together would revolve around vagaries of nature, monsoon, labor shortage and the like, though I recall very little discussions on agronomy or the business of modern agriculture as western farmers know it.

That image of farmer extended to that of a “grower” after I joined my employer. Perhaps because farming and agriculture is a vocation, engaging with Mother Nature. And for most, if not all farmers, even for subsistence farmers, growing is a “business.” Even subsistence farmers aspire to eke out a bit more out of the land that they can barter for other life’s necessities.

Farming: Business, government and society

Policy makers and governments around the globe struggle with “food security” issue, feeding 7-8 billion people with limited resources that Mother Nature provides. Some of the answers lie in the judicious use of science and technology to aid modern agriculture including use of “sustainable agriculture” techniques, chemicals – fertilizers, pesticides, herbicides – and genetically modified and hybrid variety seeds that can ensure greater, consistent crop yields on limited land and resources available for agriculture. And this is where the business of agriculture step in.

Agri-business value chain is complex, and includes “input companies,” like my employer that are engaged in the business of research, manufacture and supply of crop-protection chemicals – pesticides, herbicides, insecticides, fungicides - as well as biotechnology products, seeds including genetically modified, specialty breeding etc etc. Though this could be lifted out of a ag-biz promotional brochure, the goal is simple:
  • Maximize yield for the grower and minimize risk of loss from pests, weeds etc 
  • Enable sustainable farming with minimum resources – land, water, labor etc – at our disposal
All this to what end? Feeding the ever growing human population. And what you won’t always see in agbiz brochures is the increasing theme of enabling sustainable bio energy, ethanol and bio fuels!
Farming and Technologies

Twenty-first century agriculture is much more sophisticated and technology driven than most of us realize. On one hand we have large industrial scale mega-farms that use of GPS, automated Chemigation and irrigation systems, water pivots, genetically modified and hybrid variety seeds, sensors and drones and satellite images to monitor crops. On the other hand, we also have small subsistence farms like those prevalent in much of Asia and Africa where millions of farmers subsist on extremely small land holding. And in between the two extreme, we have all varieties of farmers including Ogranic farms, serving niche markets.

Enterprise Architects multinational agri-business firms, just like our peers in other businesses have to continue to focus on BDAT dimensions with the firm goal of aligning IS investments with business drivers. A sampling of architecturally significant use cases:
  • Supply chain: complex forecasting, demand planning manufacture, production, distribution of seeds and chemical products. Of course, some of this has an added business twist. The production of parent seeds is also impacted to a large extent by the issues our growers face: vagaries of Mother Nature. The supply chain of agro-chemicals is highly regulated by federal, state and local authorities, with an increasing focus on security. 
  • Partner integration: An agbiz company like most large multinationals has to integrate with partners, suppliers, vendors and others to ensure seamless interchange of data and information. 
  • Enabling Research and Development (R&D): In this business, a new product can take nearly 10 years from ideation in research to getting to market with a series of complex steps in between. Emerging technologies including analytics, big data management, high performance compute are increasingly being adopted to enable accurate, faster time to market. 
  • Thinking of future of farming includes scanning horizon to bring in newer technologies. This includes enabling complex agronomics enabled by timely information and data. Emerging thinking includes Digital Farming, Precision Agriculture, use of GPS, satellites and drones – enabling “use” of data. All of it targeted to provide actionable insights to end users, (in this case) here the grower.
Just my two cents and by no means a comprehensive list of the critical role of Information Technology plays in managing the complexities of agribusiness. And somewhere there comes to critical task of defining the blueprint for Enterprise Architecture that streamlines the process of bringing new techniques to the vocation of agriculture.

Links of interest

Monday, June 10, 2013

Big Data 101: Thinking beyond National security Agency

Federal government investments and initiatives have long shifted the needle on technology innovation and adoption. Almost every case study on government funded innovation has a mention of how internet has its genesis in defense department’s DARPA initiative.

Last week, American public woke up to the fact that NSA, CIA and other security agencies were gathering phone records of some/most/all phone-calls to and from the United states, setting off a large public debate, perhaps what the whistle blower Edward Snowden wanted in the first place. It was interesting to hear US Senators and Congressmen try to explain technical jargon like metadata and applications of big data to their constituents. About how the call records turned over to federal agencies were just metadata of calls and not actual content of calls.

Corporate IT executives and CIO’s have already begun to recognize the value that good data analysts can bring and this incident is only bringing renewed attention on the potential of big-data. An unintended consequence of this saga, perhaps the real silver lining here is for technologists. Now that the program is out in the open, I wonder if there will be argument to commercialize the “mechanics” to reverse-engineering some of the big data technologies being discussed. One can argue that similar technologies used by NSA and federal agencies to gather and analyze large volumes (“big data”) of metadata about telephone records, can be used by commercial organizations. Say to parse through large volumes of data required for in-silico research to speed drug discovery.

Big data spells big money, not just for corporations. Data Scientists are already among the hottest category of IT professionals in the market. Play this out against the immigration debate and the message to younger generation of technologists in America is clear: plan a career in data analytics and science!

Other Links of interest
  • While it is news now, the media has been talking about it for a while. NSA data center front and center in debate over liberty, security and privacy (Fox news article in April 2013)
  • NSA's Big Data Platform Faces Enterprise Test: Accumulo, the data storage software developed by the National Security Agency, has taken another step toward the enterprise market. Sqrrl, the startup launched by former NSA technologists to commercialize Accumulo, has teamed up with Apache Hadoop provider Hortonworks to combine their technologies.
  • NSA Reveals Cloud Plans, May Open-Source Some of Its Software
  • Hadoop is an Open Source Revolution: Federal Computer Week Interview "Hadoop, and a handful of open-source tools that complement it, has no equal when it comes to making gigantic and diverse datasets easily available for quick analysis using clusters of inexpensive computers"

Thursday, June 7, 2012

Facebook fizzle does not dampen Developeronomics … because not every code coolie is an Über coder

As we enter the middle of 2012, the global economy continues to stagnate and even the erstwhile darling of stock market – tech sector – begins to flounder. The butterfly effect seems to be hitting technologists at both ends of the spectrum - entrepreneurial and software services.

Last month it was the Indian software services darling (my erstwhile employer) Infosys, warning of severe headwinds in the global technology services sector. Then it was technology giant Hewlett Packard announcing massive job cuts. And then came the mother of all IPO’s of tech darling Facebook and its spectacular post-IPO-stock-fizzle, leaving most of us in the globalized IT world wonder whatsup?

While the macro-economic factors play out in the business of technology management, interesting conversations on Developeronomics continues to stir among the Digerati. The debate was triggered by Marc Andreessen’s essay in Wall Street Journal: Why Software Is Eating The World. Marc espouses the theory that we are in the middle of a dramatic and broad technological and economic shift in which software companies are poised to take over large swathes of the economy.” The techie in me loves this argument though I still wonder if we are really seeing a Technology Lead Innovation around us or Technologists playing catchup? (my earlier blog)

Marc ends his essay with key challenge facing software economy “Qualified software engineers, managers, marketers and salespeople in Silicon Valley can rack up dozens of high-paying, high-upside job offers any time they want, while national unemployment and underemployment is sky high.” Although he doesn’t say it in as many words, the challenge Marc highlights is more about the dearth of Über coders, while the world – or at least the offshoring world – continues to produce thousands of code coolies.

Although the use of term code coolie may sound a bit derogatory, it really is intended to drive home the point that vast majority of coders are developing software as a means to earn a living. They do it as a vocation rather than with a passion to enable software to “change the world” in a significant way. Remember the storm in a teacup when the Indian writer Chetan Bhagat tweeted on "Narayana Murthy runs a body shop?" Of course, graduating a hundred thousand techies in a decade is no mean feat. And that is just Infosys. Add TCS, Wipro et all and one can see the challenge is really not about the ability to get a critical mass of coders.

Then there was an interesting piece on “The Rise of Developeronomics” in Forbes, which took a broader perspective on IT development and developers stating “If the world survives looming financial apocalypse dangers at all, this is the one investment that will weather the storms. It doesn’t matter whether you are an individual or a corporation, or what corner of the world you inhabit. You need to find a way to invest in software developers.”

Businesses have already taken note of the importance of software developers though many leaders are trying to crack the core problem: bridging the long tail of code coolies to the few Über coders around. To create a successful eco-system where thy can not only coexist but can also thrive. To take an anology from another domain, it is akin to identifying the right general to lead the army to battle.

This question of variance in productivity between the best programmers and average coders has been debated ad infinitum by the software community. However, it is not just about recognizing variance in productivity but to ensure the right mix. As the Joel Spolsky blogs “it's worth hiring Angelina Jolie for your latest blockbuster movie, even though she demands a high salary, because that salary can be divided by all the millions of people who see the movie solely because Angelina is so damn hot.”

What does all this mean to us?
  • For IS leaders it is a continuum of trying to find the right teams to develop the right solutions for their business stakeholders. Techniques include outsourcing, hoping the vendor will crack our business problems with a team of uber coders from across the globe (there is always hope). Hiring uber coders is always an option but it involves competing for talent with Facebook or Google (tough luck doing so!).
  • For enterprise architects - self included - it means working with technologists and business stakeholders continually tweak proposals to bridge the divide
  • And for business stakeholders: Empowering your technology leaders and Enterprise Architects to help with Developeronomics
  • And for the mass of code coolies? Try and morph into an Über coder. And if you discover that is not your calling, well we shall cover that in another post
Blogs and references

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

Thursday, October 20, 2011

Congrats : 2011 Enterprise Architecture Awards Winners

Enterprise Architecture as a practice continues to evolve. While consultants and experts in the industry debate over the role of EA in technology and business, Architects in successful organizations continue to guide, mentor and steer their business and technology teams to leverage industry best practices.

Coagulations to Enterprise Architects for making it to the top of the 2011 list:
  • American Express
  • Bayer Healthcare
  • First Data
  • Singapore Ministry of Education
  • Proctor and Gamble
  • USAA 

Ref: The 2011 Enterprise Architecture Awards from InfoWorld and Forrester Research
 
Successful EAs seem to be doing the right things:
  • Help define the right roadmaps and guide teams to work towards them
  • Enabling "knowledge bridge" between business operations and IT
  • Create a framework for strategic technology programs to coordinate technology adoption and development in a manner that maximizes value
  • Moving away from being hostage to a legacy of dysfunctional IT, help the organization transform into an agile organization that embraces change
  • Digitize and simplify its end-to-end processes
  • Experimenting with different approaches to presenting data and collecting and maintaining architectural elements

As a consulting Enterprise Architect, I have had the pleasure of working with EA’s from organizations that continually move towards top of these lists. However, the challenge I continually see is that not all Enterprise Architecture organizations do all the right things all the time. 

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