Software Development

IT: Becoming less about tech skills, more about integration

Patrick Gray talks about a seismic shift going on in IT where knowledgeable technicians no longer rule the roost.

It's an amazing time to be in the IT industry, as we're witnessing a seismic shift the likes of which rival the move to connected computing inspired by the Internet in the late 1990s. While the Internet had near-universal appeal to IT workers, this next shift has raised some eyebrows.

Increasingly, working in IT is becoming less about technical skills and more about integration. Whereas in decades past your key players in most IT departments were the exceptional developers, key roles are increasingly filled by those who can best integrate readily available components. Even software development has moved in this direction, with the most capable developers being the ones who can creatively write the "glue" that leverages existing libraries, connects to external services, and delivers a new experience in weeks that would take months or years to develop from scratch.

Arguably, this is the direction in which computing has been going for years, from the first shared libraries and software development toolkits. However, we've only recently shifted from the days of proprietary and costly libraries to open APIs, with a breadth and depth that would have been unfathomable a decade ago. On the software development front, anyone with an internet connection and web browser can tap into everything from freely available open-source development environments to cloud-based storage and processing power that offers more capability and capacity than most Fortune 500 IT environments. Each new application that leverages these tools seems to adopt the philosophy of the major cloud providers, offering low-cost APIs that further the innovation cycle by allowing a new tool to tap into each subsequent technical evolution.

What does this trend mean for IT?

The term "enterprise architect" has become a bit hackneyed, but the analogy is a good one. An architect may not be the best person to swing a hammer, but does have a good idea of modern materials, construction techniques, and vendors who can execute their vision. They also bring knowledge of broad regional and industry styles and trends to bear. While there are still roles requiring deep technical experience, for most corporate IT workers their role will shift from implementation to architecting.

For IT leadership, this fundamental shift in the industry means several things. First and foremost, IT leaders must help their staff manage the transition to this new world. Traditionally, IT leaders have struggled with what they consider HR issues best left to the professionals, but your staff are going to require new skills, modes of thinking, performance monitoring, and rewards structures. Essentially, facilitating your staffs' transition is simply too important to leave to HR.

Similarly, the change will require IT leaders to shift from proposing and delivering large-scale implementation and infrastructure project, to closely collaborating on unfamiliar turf from purchasing to legal, as outside parties increasingly host critical pieces of your technology infrastructure. Old vendor relationships may no longer be as critical, and you might end up dealing with anyone from Amazon to Apple, players who only recently began to play in the enterprise space.

Moving forward

It may be tempting to lament the loss of the past world, where the strongest coders and most knowledgeable technicians ruled the IT roost, especially if you're an IT worker or leader struggling to come to terms with this new world. What I find most exciting is the opportunity this transition represents to revitalize our industry. No longer are the cutting edge tools restricted to the domain of massive companies with eight-figure budgets. Now that someone sitting at their kitchen table can access the latest and most powerful technologies at commodity prices, we're in for a period of innovation the likes of which we haven't seen since the heady days of the dot-com era.

About

Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...

62 comments
kharsha27
kharsha27

mainly have experience and knowledge

evincent
evincent

This is nothing more than a representation of the overall "dumbing down" of the overall workplace and the whole "do more with less" mentality. As others have already commented on this article, IT still requires the highly skilled technical folks. These "integrators" are nothing more than a euphemism for what we are seeing more and more of in IT - folks with poor skills who pretend to be incredibly talented just long enough to land a job and stay there for about a year before their employer realizes they are worthless and they move on to the next job to repeat the same process. The problem is that it has become so prevalent that its now accepted as the new norm. It's also a sign of the "do more with less" approach to business. IT managers now have to deal with HR issues because there's less and less HR staff to adequately support the organization.

davidmartinomalley
davidmartinomalley

There are gaps in the argument, but it comes down to a "value" proposition. In the past (think, the .com days) it was all about the code. Your value was defined by the language you used and how good you were at banging out the syntax. Believe me, I lived it! But now, Code is a Commodity. And like all commodities, it's a race to meet a threshold of quality for the lowest price. If you are a "coder", you are competing with people all over the world to produce this commodity. "Integration", IMO, doesn't mean connecting pieces of code in one system, with another, it refers to Business Integration and Technical Leadership. It's about delivering solutions, not code. It's about building relationships with Business Leaders, understanding Business needs, and delivering quality products and services to meet those needs. That level of IT Integration is much harder to commoditize. Do we still need code? Yes. Raw technical skills? Of course. But we'll simply get those components from the lowest bidder. If you live in the first world, or if you're over 40, that's not good news for you.

RMSx32767
RMSx32767

What nonsense. The folk most likely to successfully integrate the technology are those with the best skills and most knowledge.

SamboG
SamboG

After almost thirty years' involvement in the "technology maze", I have come to the conclusion that those who eyes are the most open will clearly see the path from need to solution, even if the journey is tortuous. Sometimes we have to fashion our own tools, clear obstacles in the path, join forces - whatever it takes. It's the journey that entices us. Now, as Patrick shines a light into the darkness, it's up to us to see more clearly the path ahead. By joining in conversation, we multiply the available dots, increasing the chances of finding a solution. Call that whatever you like. Integration, cooperation, synergism, the words matter little. I for one am happy to be along for the ride.

sseifert
sseifert

I tend to agree with Patrick's analysis. There will never be a loss for the true "hammer" swinging technician, but in the corporate environment (especially where the core deliverable of the corporation is NOT IT) I do see the shift to IT integrators and architects who understand their companies business, and can architect IT to fit the business needs. The technical skills can then go to IT commodity type vendors that provide the discrete technical expertise, and don't necessarily need to have knowledge of the business.

Sensor Guy
Sensor Guy

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.

swchase
swchase

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

michael.speyer
michael.speyer

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 :(

mr.kaeng
mr.kaeng

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.

ghazanfar_is
ghazanfar_is

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

StevenDDeacon
StevenDDeacon

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.

djo165
djo165

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

jk2001
jk2001

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.

john.masika
john.masika

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.

doug
doug

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.

gabriel2tg
gabriel2tg

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.

christinekristy
christinekristy

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

premiertechnologist
premiertechnologist

This is the bottom line. Managers are incompetent. They have [i]needs[/i] (read "lusts") to make money by knowing nothing and making [i]things[/i] happen by magic. They would like to believe that no technologists should exist. I watched the movie [i]Inside Job[/i] 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 [b]Brave New World[/b] 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 [b]White Collar[/b] 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.

jbgisser
jbgisser

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

sarai1313
sarai1313

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.

glez
glez

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

JohnMcGrew
JohnMcGrew

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.

coffeeshop
coffeeshop

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.

kci833
kci833

“Increasingly, working in IT is becoming less about technical skills and more about integration.” Sorry, but I can’t 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 PHD’s, engineers, and social science PHD’s. 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).

brilliantstar
brilliantstar

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

Darren B - KC
Darren B - KC

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

Justin James
Justin James

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

karthikkannan
karthikkannan

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

sarelklopper
sarelklopper

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.

premiertechnologist
premiertechnologist

100% Agreement. This brings us back to the quality triange: Fast, cheap, good -- pick any two. Except, thanks to irrational management, pick any three. Here we see the adaptation to social conditions which are irrational and harmful, resulting in dysfunctional environments in which nothing makes any sense at all because of distorted perceptions (of management). It's plug and play with features impossible in a rational universe. I know two things: 1) You cannot solve technical problems with politics; 2) You cannot resolve political problems with technology. Unless you are talking about a loaded gun, in which the political situation is actually made worse once you use the appropriate technology. It's truly unfortunate that we are required to develop technological solutions with a gun to our head by managers who don't have a clue what they are doing -- but do it anyway... and do it with progressively fewer resources! We have to make our numbers to keep our jobs! Not credible? The last words that my IT Director said about herself to me should suffice: "I don't know what I am doing". That explains a lot -- about what we are seeing as a pandemic epidemic of wrong choices and worse results. Yes, management will start another impending failure with a new set of components: It's called milking. And it works. For awhile. Until some poor schmuck stumbles into it as the perpetrator takes leave for even richer fields of gain in a promotion or moving to another venue (in the corporate scoundrel recycling program), after which said schmuck is doomed, while the source of the problem profits from the angst of those he has duped and left behind. It's a perfect system.

Tony Hopkinson
Tony Hopkinson

100% agreement. As far as business is concerned, the argument is if a new tool enables a competent person to be better, it will enable a far cheaper less competent person to do "well enough". Where the wheels always come off if they survive long enough, is that well enough yesterday, is completely unacceptable tomorrow. To keep surviving you have to maintain at least some of the return on the initial investment, you need competent techs. All cookie cutters can do, is start another impending failure with a new set of components.

Tony Hopkinson
Tony Hopkinson

Bulk of my work is using my technical skills to make those lowest bid components actually work, never mind togther... Just coding became an endangered species of a job decades ago, I'm still here, many components and the people who failed along with them aren't.

Tony Hopkinson
Tony Hopkinson

In order to properly integrate with Product X we must completely rewrite product Y. Okay IF (if, yeah right) we don't do that how much integration would we get. Now X and Y are integrated... (erm no they aren't, more like intermingled..) Why can't you do XY... (Sigh) I recomend you don't talk like this to your boys at the sharp end, its got to be really irritating.

Tony Hopkinson
Tony Hopkinson

must have operational experience. Lost count of times I've seen that one catch up with the classroom/speciality driven. Integration is necessarily holistic, missing out significant portions of the usage domain, means a lot of other things get omitted as well.

gechurch
gechurch

I love the concept, and it's one that's been around since almost the dawn of programming. The problem is the interface between disperate applications. To work together programs need to have defined a clear set of rules regarding what they will expose to outside programs and how outside programs will access these functions. Someone has to define this interface, then spend time coding it up. And once that boundary/interface is defined, any changes risk introducing bugs in outside code that interacts with your program. Microsoft probably have more interfaces/APIs to maintain than any other company in the world, and they are intimitely aware of the problems seemingly inconsequencial changes can cause. Raymond Chen's blog is a good read if you want to get details on some of these support problems. It's full of entries like how an undocumented registry key still exists today because four programs started relying on it based off the beta of Windows 95. The reality is there are not clean, well-defined boundaries that let you 'click' together different programs. No-one takes the time to write them because they are too busy adding features to their applications. (People pay for features). And even if these clear-cut boundaries did exist they wouldn't be useful for long because as you add new features and remove existing code the boundaries defined would no longer match up to the new code/feature set. No amount of staff motivation or project management will ever change that.

jk2001
jk2001

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

jk2001
jk2001

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.

sarai1313
sarai1313

you "I.T." experts did not even know the reson why windows 8 has suport for 8 bit 16 bit programs. so do not tell me about how smart you are and how dome i am .when some one can tell me how many buliding automation systems or car companys or other sevices still use 8 bit or 16 bit systems get back to me.i wont even get into the government still useing 8 bit programes and why they still use them.

gechurch
gechurch

A web site isn't a very good example - it's a solved problem. For a simple web site all you need to do to "integrate" the template that is to replace the placeholder logo and content with your own. By definition you need to write code because the problem you are working on is not already solved (if it was you'd use the existing code). A more realistic example of integration is getting your accounting package and your job tracking package (from a different vendor) to talk to each other. Typical problems include: * Code you need to access that isn't available * Subtle bugs in existing code (possibly unknown, because you are now making the code do things it has never been tested doing, and possibly wasn't designed to do) * Bugs in third-party libraries that you need to work around * Poor documentation or the systems * Fundamental differences between the systems. Maybe you enter all clients into your job tracking system, and the integration is meant to automatically import the new clients into your finance package. Sounds fine, but what if the finance package requires a field like a business number, and there's no place for that field in the job tracking system? * The list goes on. And for each of these problems, someone needs to write new code to fix or work around them.

jk2001
jk2001

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.

Tony Hopkinson
Tony Hopkinson

It can be a speciality of course, but there isn't anyway a one trick pony is doing it right...

jk2001
jk2001

Integration could be made easier if all the APIs were basically identical, and data formats were identical, and APIs never changed or grew, and these services never changed or went out of business, or products got cancelled. That's not going to happen. If it were bound to happen, we'd all be using SOAP and integrating with WSDL, which have been around for a decade. That hasn't happened, because companies that provide these systems and services also have a need to stay in business, and that means introducing incompatibilities that encourage vendor lock-in... or in the case of SOAP and WSDL, avoiding technologies that benefit Microsoft, who may end up competing with you. (You can substitute any other company for Microsoft, and any handful of nominally open technologies for SOAP and WSDL.)

davidmartinomalley
davidmartinomalley

This is a classic case of survivor bias - yes, you survived, but the "coding" industry was irrevocably changed when that skill became a commodity. If any "first worlder" is happy with a defined ceiling and the threat of being outsourced at any minute, then coding is the job to be in. If not, then be that business integrator who moves the pawns on the board. It doesn't mean you forget your technical skills (far from it, actually), but you won't be practicing them. Others will.

gechurch
gechurch

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.

Tony Hopkinson
Tony Hopkinson

when that 1500 lines of cost turns out not to do exactly what you thought it did, or even more likely stuff you didn't want it to. Next step, call in someone with some technical skills. Cookie cutting was meant to improve productivity in the competent, all too often it's used to reduce unproductivity in the incompetent.

Tony Hopkinson
Tony Hopkinson

I was there when the industry changed. I welcomed it. In some places I helped drive it. Despite my distaste for the utter stupidity underlying commoditisation, professionally I've done very well out of it. I'm the boy people employ to put the wheels back on and I expect my chosen career path to last another few decades, because despite real evidence to the contrary, people like you are still telling them what they want to hear, not what they need to. As soon as you create a set of components with a level of complexity and applicability to meet a wide range of needs integration is programming in another language. I do way more than survive.

gechurch
gechurch

I'll check out the documentary. Sounds like something I'll enjoy. I agree it's a pandemic.It's pretty rare to find a good manager. I think for every manager that's bad because they're too self-interested, there's probably 5 who want to do a good job but haven't received good training, good guidance or good feedback.

premiertechnologist
premiertechnologist

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!