Welcome!

IT Is Power. Try Living Without A Single Breadboard For A Day.

Don MacVittie

Subscribe to Don MacVittie: eMailAlertsEmail Alerts
Get Don MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Big Data on Ulitzer, DevOps Journal

Blog Feed Post

Should IT Model Construction? By @DMacVittie | @DevOpsSummit #DevOps

There’s a lot going on, and it’s getting more complex

I’ve worked in just about every job in tech. For this blog, I’ll mention the two roles likely to come up again later – Manager of Enterprise Systems, and Enterprise Architect. Both pretty cool in their own realm, but vastly different roles.

Enter Construction
Before we go any further, let’s take a moment to talk construction. Much of my family is or was in construction, and construction sites are well-oiled machines. They put together houses where plumbing depends upon wall alignment, and electric depends upon design decisions, where the roof needs a square set of walls to sit correctly, and where the doors count on a level floor. It’s complex, with circuit design, plumbing, etc all crammed into one. And it’s manual. A lot of labor. But guess what? They put buildings together at an amazing rate and it all comes together. Know why? Because over the years they have structured their crews to meet the needs of the job, and learned when complex systems did not interoperate. It’s not amusing to the plumbers when they find their pipe should be in a cement wall that is already poured, for example.

Image Courtesy of WikiMedia Commons

Image Courtesy of WikiMedia Commons

But most enterprises work in a land where staffing does not meet the needs of their organization in the world as defined today. Think about it, we want more visibility between teams in IT, but who, exactly, is supposed to provide that insight? Particularly in systems like Cloud and Big Data that cross many traditional silos? In construction, the Design Coordinator and the General Contractor work hand-in-hand to cover both technical and man-power issues.

You see, when I was a Manager, my time was spent on budgeting, planning, and personnel issues, not on what cool new thing Dev or Ops was playing with that the other was going to have to take account of. And when I was an Enterprise Architect, I was focused on these issues – for one enterprise-wide project at a time. Project managers are in much the same boat, they have a project to get out. They’re not (generally) pawing through the other stuff going on outside their current project.

There’s a Lot Going on, and It’s Getting More Complex
As the amount of new technology coming in the door goes through the current wave, someone needs to be keeping tabs on all that is changing, and making certain that the changes don’t conflict, and that one group is not about to blind another with some tool or process that will change the recipient’s job.

Consider if the database folks decide to implement Big Data… That means networking, systems, security, and eventually Dev will all have responsibilities to the Big Data team. Who gets final say in how things are implemented, and who makes certain these groups are aware the workload is coming – even if you’re only going into a “pilot”? In my experience, Big Data Pilots run from 10-15 machines quickly up to 100 or more in an organization that finds value in the tool. How this will work should be determined early, not after the pilot is a “success” (only in quotes because it is defined by your org, so is different for every installation). From my more recent work, using products like StackIQ Boss, you can throw up a big data install in minutes. But that ignores networking, security, asset management or VM deployment… All things that need coordination, even though you could “just do it”. The same is true with Stacki, you can download, install, and spin up hundreds of Linux servers in minutes, but where are you going to get the servers or the VMs to do so? And what impact would that have on the network?

Similarly, Docker can cause big issues between groups. While it is simple for a lone-wolf like myself to throw up Docker on their laptop, and use command line or something like Kitematic to spin up instances of whatever I want, when those machines head off to production, they need to be locked down, configured on a server in the production network, have networking configured for them because they’re no longer taking advantage of your desktop networking… A simple thing that is astounding in use can suddenly become an issue if proper planning isn’t involved.

Even something as process oriented as how and when to implement sharding (either app or DB) has an impact across IT that will need addressing, whether someone is arranging that communication beforehand or after it is too late to make changes without wasting work.

This same scenario can be run through for other popular new tools from Jenkins to OpenStack. Some inevitably come to the conclusion that you need your entire culture changed and to adopt DevOps to achieve this goal. They’re not 100% wrong, but I think they go too far.

What you need is someone with authority and insight on the tech side. In smaller orgs, the CIO does this or sees to it that his direct reports do, but that stretches relatively quickly with the other pressures placed upon management – from interfacing with the business to staffing within budget.

Some organizations want Architects to do this, and that’s not a bad plan at all. Except that most do not do this today, and they don’t currently have the time, authority, or insight needed to achieve the goal of smooth implementations. This is not their fault, the Enterprise Architect role was created to get enterprise-wide initiatives implemented across silos, which sounds like exactly what is needed, but alas, it is not. While implementing a new Intranet and juggling all of the different groups that need input to such a massive undertaking, the architect is not looking at all into the future of portions of IT completely unrelated to the intranet, and at what some genius-level staffer in Ops is implementing to make Ops easier, let alone considering how this tool will impact other parts of the org. And they certainly don’t have the authority to say “You need to talk to security about that.” And enforce it in most orgs.

The thing about “cultural change” is that it’s across the board, when all that is really needed is someone who can understand the tech and take the time to say “you and you need to talk, I’ll schedule a meeting”. Of course, it takes time to learn the tech and understand how it will be used, so “cultural change” is faster… But I think that most DevOps fans forget that sometimes faster isn’t better. These teams have other work to do, more than just discuss where they meet and are dependent upon each other. A little bit of time lag – as long as it’s only a bit – is just fine. We’re talking about teams that (for older companies) sometimes went decades without significant change, and even though things are different now, a week or two delay while the tech and fit are felt out is not that big a deal in comparison.

So What Do You Need?
Just as most Enterprise Architects are the PM group’s cross-team hammer for a given project, this role needs to be the same, but for all the other things going on out there, not just one or two projects at a time. Just as Business Analysts are aimed at interfacing business and IT, making certain IT knows what the business needs and the business knows what IT can deliver, so internally does IT need an Infrastructure Analyst that can make certain everyone is aware of what is coming. Someone who understands – at least a little bit – each part of IT, and how they interact, what dependencies there are at least at a high level (like what all is necessary before that VLAN in the lab can be hooked up to AWS, for example – from networking, security, and if a VPN endpoint is required, possibly from systems).

Could you task Enterprise Architects or Team Leads with this role on top of their existing workload? That depends upon your organization, but I seriously wouldn’t recommend it. EAs are doing important stuff, and I’ve not yet seen the company that thought “Gee, wish we had less people on the Architecture team”, and Managers are busy staying abreast of inter-departmental issues and personnel/staffing issues.

It really doesn’t much matter what you name the role, it needs to be set up with the authority to call meetings cross-team, to look into any given project on any given IT team (and history says on shadow IT teams too… This is not a new problem, it’s just bigger today), and be knowledgeable enough in the breadth of technology to understand issues and concerns. Ideally they should be given the responsibility of making the final decision if two (or more) teams disagree on the helpfulness/feasibleness of tool or process X (non-business, infrastructure stuff. The business focused issues are already handled pretty well in most orgs, by starting with “It’s what the business needs” and modifying by “Is that even feasible?”)

Just One Voice in a Crowd
Will others offer you different advice? Oh absolutely. Some think you need to change your entire culture, possibly even your entire organization. Some will advise you that you don’t need to even consider a position like this, for a variety of reasons, and some will argue that the rate of change needs to be faster. That’s a good thing too, because every org is different, take what each of us says into consideration, and then decide what suits your org the best.

Read the original blog entry...

More Stories By Don MacVittie

Don MacVittie is founder of Ingrained Technology, A technical advocacy and software development consultancy. He has experience in application development, architecture, infrastructure, technical writing,DevOps, and IT management. MacVittie holds a B.S. in Computer Science from Northern Michigan University, and an M.S. in Computer Science from Nova Southeastern University.