Discussion on:

IT: Becoming less about tech skills, more about integration

You make it sound like Integration/Solutions Architects have no appreciable technical skills.

To be honest pulling all this together probably needs broader and deeper technical skills that for a single Enterprise Suite that all pulls in the same direction. And when that all fails, developing sellotape solutions covering your arse with FTP, scripts, Remoteware and all the best operating practive housekeeping/maintenance developers/solution architects miss off the main project deliverable.

The article is spot on. We're a SharePoint company, I'd like to put development company but 90% of what we do is finding code on the net and gluing it in place.

A lot of what we do is around user interface in the browser so for us it is the interface between SharePoint's ASP, HTML and JQuery - and then Visual Studio for the server side stuff.

But occasionally we need to do something that hasn't been done before and then suddenly we need to write new code. If it wasn't for the original coders then we'd be completely stuck.

All programs are integrations, they all have an architecture. They all sit in an environment. Plugging existing and off the shelf software together to achieve integration, is simply programming at a higher level of abstraction. While you could argue that someone who does that doesn't need to know the exact detail of the implementation of one of those modules, just like you could argue that a programmer only needs to know an API and not the dll it provides an interrface for, only the ignorant would believe that the details of that implementation won't affect how integrated a solution is.

What you seem to be advocating is architectural cookie cutting, you should bear in mind cookie cutters reduce costs by reducing quality, they make nothing better than those who are competent...

Do you know that even today, there is no one single acceptable API to upload a file ? Or do any of the zillion things needed to make everything work together.

This kind of talk creates two layers - those who are somehow "managers, co-ordinators, big thinkers" and those who are "mere workers". More and more companies are finding out that they need workers, doers - because technology is simply moving too fast to be left to those who read it all up on Google. Either you do it, or you know nothing.

And it is very easy for those who write code to fool those who merely know the keywords. Trust me.

Great article.
I agree with this article. Software development has been advanced by having higher and higher level of abstraction.
However being an architect does not mean we can always ignore implementation detail. Sometimes interface does not work as it promised.
Joel explains it nicely here http://www.joelonsoftware.com/articles/LeakyAbstractions.html.

It always was and still is about understanding the technology. The key is to also understand the needs. One must have a very good grasp of the technology to be able to architect solutions. It's the proper application of the technology that best fits the needs. The best architects also know how to swing the hammer very well.

I can say from my personal experience, integrators are a bunch of bullocks.
For small non critical organisations this works fine. For enterprise and core business you are jumping off a jumping off a cliff with balloon tied to you by a chain, even if one link fails you fall to your death.
Most technology does not work as advertised, even if it works, it may have something that is not exactly solving your problem.
I have examples for these, back in 2004 i needed to write a software that used to be a glorified CMS. We decided to use ftp to get/put files from the server. Everything was fine till the program started hanging, the problem was in the API that i had used for create the FTP connection for me, when we got a directory listing the connection was not closed properly and this caused the API to hang on till the connection was closed, (120s), which was totally unacceptable, so rewrote the whole program using a different API.
Everything is sunshine till it fails. Then you need the technical know how to actually get the thing working again. If its third party, then starts the blame game "you are not using it right", "our program is working fine here", "check you infrastructure".

2004 was 8 years ago. That's a long time in the IT industry.

If "Moving Forward" and "lament the loss of the past world" is trusting 3rd parties to get it right, you will reap what you sow.
We all know that theres no perfect fit in any implementation, don't pretend there is. Your lying.

And the reality of this approach "Now that someone sitting at their kitchen table can access the latest and most powerful technologies" means any Tom, dick or harry has limitless power to use against you. As the unwitting adopt the cloud, which, lets be honest is what this article is all about, these kitchen hogging non-techs rule the roost, not the architects.
These are the ones turning these so called architects babies inside out, and after being fired, those architects are in the proverbial kitchen.

Every time I see this swill, I want to throw up. Integrating systems increases complexity and thus the skill sets required to complete and maintain that integration. Furthermore, when you start integrating with "The Cloud" and third parties, things are complicated even more.

To use the articles analogy. In the 1800s an architect would design a building, and with two or three trades that building could be built. Over the next couple hundred years architects designed bigger, more complicated buildings, new technologies were included in the design as well. Today buildings are more convenient to be sure, but they are also bigger, more complicated and require many more trades in order to build and even simply maintain them. Eventually the HVAC system must be upgraded without upsetting the operation of the building, then the electrical system needs an upgrade, then the plumbing.... All of this has to be accomplished without interfering with the day to day operation of the building.

Sure the architect can have a grand design, but without the skills of all the trades, working together, that grand design will never get built, or maintained!

Yes John Doe, sitting at a kitchen table can use some canned app on the cloud, but ask him to integrate that app with another app from another company and different data and then merge that with the data on his iDevice and see how far he gets. Good luck with that. I dont' think it will work out any better than asking him to build the Empire State Building.

We have worked on several solutions and most of them was to integrate into existing solutions. Companies simply no longer have the budget nor the time for over engineered solutions. With most solutions being web-based you will find that integration are almost being the norm. At times we have found that your more exceptional developers are finding it hard to see possible integration than ... rather interesting.

The reason for this illusion is most of the enterprise applications have similar infrastructures that solve almost same problems in the past decade... Without technical skills, we can not build the next generation applications which are dealing with different kind of problems... It requires one to learn new thinking and depth understanding of technologies to be able to solve them...

@Patrickgood1: Yup... The best architects must know and be able to show how to swing the hammer well...

If you think that "integrations" happen by someone simply telling System A to "integrate" with System B, you are dead wrong.

Integrations require "technical skill". LOTS OF IT.

J.Ja

...about nothing significant. But hey, tech authors have to write something fresh and original in order to justify thier paycheck, right? Or maybe they enjoy spreading messages of doom and gloom to people with technical skills who already feel threatened enough by this kind of hoopla.

It is a craft that builds on itself. To be technically inclined is to have hands on skills and field knowledge. Schooling, yes of course, but trust me until a person gets in the field it is all theory. The biggest shift in Technology and Business is that ~ Technology and Business are learning to coexist. They must communicate and the best way to do that is through a technical person with business savvy. A Liaison if you will. Corporate business will always need technical staff...

Increasingly, working in IT is becoming less about technical skills and more about integration.
Sorry, but I cant buy your argument. I once worked a high energy physics project in one of our national labs a while back and your topic of integration has intrigued me. The lab consisted mostly of people with natural science PHDs, engineers, and social science PHDs. The scientists mostly architected the project (the WHY), the engineers mostly did the building (the HOW), and the lab administrators (social scientists) made an attempt to manage the project (WHEN is it expected to be completed, on budget). Once a project was approved and funded, the circus began.

Yes, there were bumps along the way and some projects bombed. However, asking one to lesson their technical skills and integrate more in all disciplines, to me, is barking up the wrong tree.

Instead of emphasizing integration, how about emphasizing collaboration. I think this article is looking for that person who is a jack of all trades, but master of none. Come on Patrick, these people are called politicians (a social science).

It's true that it pays to stay on top of technology and to be creative, and oftentimes it's foolish to try and re-invent the wheel when, considering that time is money, it cna make more sense to use what's already out there. A very simple example would be building a website. Do I want to spend hours and hours writing HTML and incorporating Flash and whatever else, or can I just use a website builder to do the same? Leveraging existing technology for an individual company's needs is the same thing basically.
The flipside to that is that if i put all my eggs in one basket and become too dependent on an outside technology and that resource goes away, then what? I can't plan for every possible scenario, but it definitely pays to find balance between using outside resources when it pays to do so, AND retaining quality talent to maintain what I've built internally.

Buy a template for $60, hire someone to write the copy, and an artist to get some photos. You'll have a nice, generic website for $500 or less.

Of course, now, you have to choose from around 1000 different templates, need an SEO consultant to make sure the writing is going to drive sales, and look at 100,000 stock photos.

IT has always been about integration. If that were not the case, everything would have worked right out of the box and there wouldn't have ever been a need for us in the first place.

Integration is just becoming more widely used in this evolution of technology, welcome to the future.

just be cause it takes away from from you being needed he wrong .give me a brake..look at the numbers less and less I.T. jobs .how can you not read the numbers and not get the right answer.

According to the US Bureau of Labor Statistics I.T. is back to the levels seen in 2008 (above 4M) and has been for the last 3 quarters. With 18% of companies activities adding staff and 36% adding specialty staff and a large minority making no changes.

From April 2012:
http://www.informationweek.com/news/global-cio/interviews/232900214

...but around 1995, my uncle was in senior management at a Very Large consulting company and I was about 7 years into my programming career. He told me with great confidence that in the near future, managers would be creating systems with 4th GL languages. They would enter their requirements and push a button, and all the code would be written...and I had better abandon my programming career and become an expert on this type of whiz-bang technology. (I believe his company was pushing an IBM product at the time.) Today, I am working at a company that does a lot of integration, and I'm learning HTML, js, JQuery, PHP, ZF, etc, etc, etc. We have BA's to help the managers define their requirements, PM's to keep the projects moving along, Technical Team Leads to help everyone understand what we're supposed to do, including when to get code and apis already written, and lots of low-level coding to make it all happen. Yes, it does take some vision to even imagine integrating vs writing from scratch, but as soon as you want to integrate, you're going to need to know how. Sorry, no push-buttons, yet.

You mean you don't write your programs by using wizards, clicking on buttons, and drawing lines and circles?

I think it's funny watching those videos where they build a program that integrates web services, and the whole "program" amounts to an if-then-else statement and a dozen statements. Yes, it's simple... but only because the other 1500 lines of code are invisible to the end user. Someone else had to write that other code.

This is the bottom line. Managers are incompetent. They have needs (read "lusts") to make money by knowing nothing and making things happen by magic. They would like to believe that no technologists should exist.

I watched the movie Inside Job yesterday about the financial meltdown in the United States this past decade. The financial analysts were having a field day using something similar to this Brave New World of using IT vaporware for wish fulfillment. This sort of imagineering has led to worldwide tragedy.

What management thinks they want in management workers are the great back-slapping (back-stabbing), smarmy social types typical of a Neil Caffrey in White Collar able to throw Erector Sets, Legos and Tinker Toys into the air and have them magically rearrange themselves into working integrated networked advanced technologies which will allow them to make themselves money and create an environment where they are virtual gods, on the cheap. They view the universe as being their oyster, providing them with a lot of something for absolutely nothing. And we've lived through that in the past couple of decades and have gotten to see the fruit of that.

Unfortunately, this magic mushroom works for awhile and it takes several years to find out that the addiction doesn't get you high any more and if you don't hit rehab, it will actually kill you. Therefore, because judgment is not executed speedily, the fools are set for life (and some of them not only get their golden parachutes, they get government jobs to regulate and manage the mess, effectively covering up what they've done for years afterward).

Contempt for technologists is growing exponentially because management types view technology the same way they view their smart phones: It just works (mostly) right off the shelf, it is always available (unless you forget to charge it up), it's a utility you carry around with you, it's magic you don't need to know how it works, and -- here it comes -- hang the expense because someone else is paying for your magic technotoy.

And IT Management doesn't make it any better getting in bed with these air head pimps because they promise them magic for less money which drives the dysfunctional environment to get the technologists to work longer and longer hours and days for less money until the whole thing is outsourced to China.

But one day, the management will find that they are irrelevant because they can be replaced by plug and play.

It's like the IT Director said of herself as she RIFfed me: "I don't know what I am doing".

I think that about explains it all.

Maybe we should really focus our energies on figuring out how to eliminate managers.

Managers will always be needed. The problem is so many managers believe their job is to "be important", when in reality a managers job is to remove obstacles and burdens from those under them so they can get on with doing the work.

The current crop seems to be worthless.

If you really want some depth on this topic, consider the 2010 documentary, "Inside Job", detailing the cause of the 2008 world wide meltdown.

Managers are there to provide and coordinate the resources that are needed for the workers and technologists to get the work done, not to be some Oriental Potentate religious cult leader who exists to collect money and power for selfish interests.

We've lost a lot over the past 5 decades, and it isn't just the technologists who are affected: The problem is pandemic.

I wonder where the dedication to duty, the pride in workmanship, the ethics and the self-motivated drive for excellence has gone.

Are we the only ones left?

Lord, take me now!

Most companies will hire IT pros who understand their business processes. It is only then they can best support their business and users

I think without technical skills, one will be able to properly ensure the integrations. A good understanding require a good grasp of technical skills to a perfection.For one to be able to understand a Business requirements, he/she has already a good understanding of the technicality involved and will be able to access the nitty-gritty of the demand.

I was wondering what our future is going to be in a world where a non-technical business owner can setup his company network in about an hour on Google Apps, and the most specialized business software is available on the cloud for a few dollars a month.

Nice to know us IT people will still have a place.

A great article indeed. Key to process/data integration is the ability understand the various functional areas which we IT people support. Unlike other professionals, we must have a bit of understanding of Finance, HR, purchasing and logistics, legal etc processes and data. This is simply because you can not integrate processes which you do not understand though it is expected that you will work with the functional experts. Now my question is; should we start investing in education to understand the business side of our organisations??????. In my view , the techie skills will still remain relevant.

I think the real trend is that there are more choices and APIs to consider. The web lowered the barrier of entry to providing data services, and also raised the bar on the richness of the service offerings. I think integration is more difficult than ever, because you have to evaluate more options -- and it's not like integration is any easier than before. You still need to write some code, and nowadays you really need to write a lot of test code. Technology complexity tends to follow innovations in simplification -- as it became easier to find files via search... the number of files we expect to manage increased. As it's become easier to browse API docs, and use them via IDEs, APIs have grown in size and number.

"While there are still roles requiring deep technical experience, for most corporate IT workers their role will shift from implementation to architecting."

Not for MOST roles, no. I work for a very large global IT service provider, and we have so-called architects that are much like management in that they believe everything they read from the vendors. So they then think that a project should be as easy to assemble as pieces of a puzzle. But the real world doesn't work that way. It takes builders, i.e., the technically savvy grunts, to fit the pieces together and make them work. And if an architect hasn't done any hands on work in a few years, they soon lose their technical chops, if they ever had any.

This statement is the truest thing on this board ==> The best architects must know and be able to show how to swing the hammer well... .

One cannot possibly understand or integrate technologies without a thorough understanding of the technologies' features, functionality, and interfaces to properly implement and manage the integration using a System Configuration Management paradigm.

In a broader/general sense this is true. We are experiencing this at our work place. A few years ago we would have bought servers, storage and maybe some networking equipment to stand up Exchange. Then the Exchange administration skills to manage it all. This year instead was about transitioning to Office365 mail. No more Exchange on site. The same is now becoming true for Sharepoint and dev/test environments for our some of our core applications going to Azure. While we do need technical people to manage the infrastructure we still have, the greater portion about the job is managing the "cloud environment".

We have a small team of software developers as well. As the article states, their jobs are more about "glue" programs today as compared to 5 to 10 years ago

So basically IT will become just like the rest of the business world with a micro-eco system within its own paradigm. Lets have spend money on It Consultants, who recommend a certain system, then spend more on this IT Architect to draw up our blueprints, and spend more money on IT Integrators who'll look at the blue prints and use a third party tech/developer team to try and bring alive this frankenstein only to find out that hey we've blown our budget? seen it too many times. These so called architects and consultants that have no real-life tech skills will never look at the cons of integration or how current staff in the business can adapt. To me this is a bunch of bollocks and the write up seems more like a sales pitch of what the author's company does. Personally i believe that all these other IT roles surfaced simply because Techs could not converse and compromise within their own department let alone other business departments.

There have been lots of analogies posted here so thought I'd give a simple real-world example of my own experiences in the "apparent" shift in IT service delivery.

My key skills lay in creating technical solutions for replacement / enhancement of manual processing and integrating those new processes into existing infrastructure.

Now, if we were to believe that technical skills were becoming less important, then how could I ever envisage such solutions? I need to have a thorough knowledge of a broad range of technologies to understand their benefits / shortcomings when coming up with solutions. To suggest that my role is becoming more important is correct however suggesting that the technical abilities which FACILITATE this are less required is plain bonkers. If I weren't up-to-date with technology I would still be suggesting the use of DOS batch files and QBASIC apps as a solution to injecting xml data into back-office systems.

Is the author suggesting that I leave the technical knowledge to someone else? Would that someone have the vision and high-level business understanding required to deliver a solution properly? Would we be able to effectively communicate on a level playing field?

The article seemed to try and make a broad and far-reaching subject fit into a little box. It doesn't work that way. We all have our roles and we are all important regardless - businesses simply need to learn to use ALL resources effectively before poo-pooing specific functions

Patrick is right. There are too many technologies, too many moving parts and too many vendors/stakeholders for us to be good or expert everywhere. We may all be able to handle a hammer or a wrench but that does not make us carpenters or plumbers.

To look to the future of IT we need to look to the past. The future of IT is the application of the assembly line concept - where each section does a discrete job (overseen by someone with a bigger picture) and the result is a finished product of defined capacity, quality and variability.

The individual(s) with the bigger picture need to know how the jobs under them work but they do not need to be expert at them. They just need to be able to delegate the tasks to those best able to perform them (technical skill), motivate their staff (people skill) and keep them all "rowing" in the same direction in unison (project management skill).

I read the authors short bio and the other articles he's written to see a more holistic view of the individual and why this article is so misleading, yet typical of today's financial management and "strategy consulting" views.

First of all, the individual isn't really talking about all of IT. He's talking about a segment of the IT business, the part that consumes and uses IT. When a vendor or product developer reads this, he would think the author is nuts. The IT product development business, although becoming more standardized from a consumer point of view with "consumer API's" is actually more complex and requires more of the technologist (multi-language and multicultural users, patents, testing, license use, more processors, packaging, mobility, etc.) than ever before. This author clearly either mislabeled "IT" or he doesn't understand the various segments of the IT market. Looking at his resume, I think it's just a case that he's only operated on the consumer side of the business, but stretched his title beyond his capabilities.

It appears to me that the author only focuses on small enterprises or "point solutions" in the IT consumer space. "Niksad8" makes an excellent observation in that as the number of solutions to be integrated rises and the age and core technology of the integrated portions becomes more varied, the problem becomes much more complex, many times insurmountable. Vendors also make it difficult because they all want to avoid commoditization through "standard API's" so they add their unique twist to each API which sometimes leads to many integration failures during development and implementation. Even worse, there are many failures integration months, if not years down the road which require detailed knowledge of the API's and technology to repair.

As a strategist, the author clearly is in the camp that IT is a commodity and can never be an asset or a market differentiator for a company. This is many times the right strategy in some industries, and is appropriate for some firms depending on what cycle there are in from a market position perspective, but clearly not the case in other industries.

The author is correct in that the nature of skills of IT personnel does and will change. Unfortunately, the amount doesn't. As technology commoditizes and undergoes its consumer lifecycle, the IT person must not only keep the past skills up to date, but assimilate more technologies as each day goes by and even more important, know more about the business and how these technologies can be applied to make the business even more effective.

Aside from the market mis-characterization and the naivety of the reality of "industry standards", the real danger in this article is the thinking by a strategist that modularity always works, can be plucked from a myriad of places and doesn't require skill and understanding to operate. The author does not realize that the rise of modularity in IT, assuming it does work well, has been accompanied by the rise in intellectual property protection and all of the technical issues associated with it. I work with lawyers a lot suing consumers of IT that have moved code from one place to another in violations of copyright, license, etc. I even see consultants copying and acquiring code illegally, placing it into another client's "solution" then the client getting sued. I bet right now a smart lawyer is looking at this author's client list and asking himself "where did he copy code illegally and I can sue?". This is one technical area of IT that is mostly ignored until it is too late for most businesses. Even consultants will charge a client for an "integration solution" many times and forget that they are selling, unless contractually specified, someone else's already paid for intellectual property.

When I ran IT shops and trained enterprise architects, I always forced them to take a temporary assignment in support and operations. If they didn't have the "career ticket punched" in operations and support, they are worthless enterprise architects. They may speak great strategy, but unless they know the cost of "strategy" they will be nothing more than designers of IT vendor pitches and industry trends. One cannot be a true architect until one knows the effects of architecture of operations. Just like real architects are made to spend time in construction, IT architects must spend time running IT shops and dealing with support issues to be truly effective. Otherwise they are just "spouters" of nice, but meaningless strategy.