Archive for 'managed services'

In my previous posts concerning my efforts at starting an IT business in my new home state of Arizona (Episode 0, part 1 and part 2), I had decided that a simple sole proprietorship was the way to go. However, I began to reconsider that course of action when I realized the liabilities involved in sole proprietorship (SP).

As a SP, all of my personal assets can be auctioned off to settle a debt. A Limited Liability Company (LLC) affords some protection to my personal assets. Furthermore, I began to have grand ideas of creating an actual business rather than simply acting as a hired gun. MSP, ISV, ASP, SaaS providor? It is all within the realm of possibilities… and it’s all suggesting an even greater need for some liability limitation. I figured it would be best to preempt the future and make an LLC now.

I found a law office in Arizona that has a ton of great information concerning the formation of LLCs in the state. While it’s specific to Arizona law, I believe that the information provided is still useful in general if you’re looking to form an LLC.

The basic information to take away is that LLCs are considered a “liability deflecting entity” that can and should be formed around any business venture. Some folks that own and rent property even create a separate LLC for each and every rental so the liabilities of one won’t threaten the others.

While LLCs can mitigate the risk of personal liability and increase the likelihood of creditors working out a deal with you, they are not bulletproof. If not formed correctly and with enough due diligence given to its continued operation, a court can “Pierce the Corporate Veil” and hold individuals accountable.

Depending on the state you live in, part of the due diligence of operating an LLC can include, but is not limited to (great, I’m sounding like a lawyer) not using corporate money to pay shareholder debts or expenses, not creating Articles of Organization, failing to hold director / manager meetings and keep minutes or filing actions by unanimous consent.

All of the specifics of the LLC formation process are dependent upon the state (or country) that you live in. Really, you should talk to a lawyer and have them set your paperwork in order.

Once you fill out the initial paperwork to establish your LLC, your state may require you to publish some kind of notice in a newspaper or on a public board and then send in an affidavit to your state’s corporate commission. For example, as of the time of this blog post Ohio and Arizona require all three steps, whereas Kentucky is one of many that doesn’t need a notice of publication.

At this point you’re finished or very near to it (depending on your state). You can then elect to receive an EIN number (again, this is specific to the USA) to use when creating business bank accounts. Business finances is a whole ‘nuther can of worms so I will leave you to consult with a tax and finance  professional (like I’ll be doing shortly).

As of this writing in May of 2010 my own LLC papers have been filed, accepted and are awaiting my Notice for Publication papers to be filed at a newspaper. once that is finished, I will have my very own LLC and will be free to take the business where I see fit.

Whew! What a responsibility. Have any of you readers trod this ground before me? Any advice would be greatly appreciated.

(Post updated to include backlinks to previous blog posts on my efforts to start a business. Thanks to Jon Angliss!)

The Corporate Executive Board (CEB) has released yet another article that suggests we IT people will have to adapt or risk being disappointed when the inevitable changes take place. The article, published on BusinessWeek.com, predicts that within the next five years a major shift in corporate IT will be taking place. It’s already happening now.

The CEB’s survey showed that in 5 years it is likely that only 25% of most business’s current IT staff will remain within the internal IT department. The other 75% will be pushed to external service companies or into what the article refers to as “shared services groups” within the company.

I’m still trying to grasp what exactly a “shared services group” is. The way the article defines it is a bit too heavy on buzzwords and corporate-isms. It seems to be a small group of IT generalists that serve the generic needs of business units in contrast to the predicted trend towards hyper-focused IT units within each distinct department. However, I’m  not sure about the article’s justification of the need for a “shared services group”.

I take issue with some of those reasons that the CEB listed for why IT departments will be fracturing. On the flip side, I tend to agree with some of their reasoning. Let me lay my thoughts out for you.

First to be mentioned in the article as a reason for IT department decentralization is the concept of outside service providers being able to better meet targeted needs: “This business shared services organization will have within it an “indispensible IT” function with specific responsibilities around managing the external providers to ensure service levels and integration with existing technology” (emphasis added)

That goes without saying, I believe. I’ll touch on service companies later in my post.

Another reason stated for decentralized IT is that: “the lines between what is “IT” and what isn’t will become so blurred that the activities may be rehoused elsewhere in the business services group.” I think that this methodology (at least, as I interpret it) may be attempted, but I’m skeptical that it will last in the long run. I see a chaotic future of disparate technologies between departments being selected and ultimately conflicting or being generally unsatisfactory. There needs to be some kind of centralization of IT, even if it’s within business units.

Speaking of business units, the next reason given for decentralized IT is that the technology that is truly making money for a business will be acquired and managed by the units themselves. The study states that the technology initiatives that add business value usually require a deep knowledge of that business function that could only be known by people who are in that unit daily. Thus IT workers will have the opportunity to be aligned directly with a business unit rather than a single internal IT department. I tend to agree with this based on my own experiences.

Finally, it is alleged that non-IT people are increasingly tech-savvy and can handle their own technology to a greater degree than previous workforces. While I agree that people have a greater appreciation for technology and aren’t so quick to make another paper workflow, I disagree that the increasing friendliness towards technology will translate into a Nirvana of shared IT duties between most members of a business unit. I believe there will still be a need for some kind of centralized strategy behind the selection, implementation and management of technology even if it’s within individual business units rather than a single monolithic IT department.

Stepping back from it, this is what I take away from the article:

First, big IT is, in most cases, dying. The centralized department of ten IT people that I was fortunate enough to work in for four years not too long ago may have been my last. Big IT is not responsive enough to justify itself.

Second, IT needs to provide actual business value. It’s not enough to just keep the lights on with services like anti-virus, application deployment, lifecycle management, asset management, email, collaboration and etc. Those services are great, but they’re as expected as water, electricity and HVAC in the building. Not one is terribly impressed with those projects anymore.

IT is expected to create systems that have a direct impact on customers. No matter what the industry, that concept seems to be increasingly focusing on either business intelligence (data mining) or some kind of web based interaction with users (in my opinion, that primarily takes the form of making user portals suck less with the help of UI people).

That puts me and every other IT person (SysAdmin, Developer, etc.) at a crossroads. In the next few years, do we want to be hyper-focused within a business unit or do we want to focus on providing services externally? Do we want to snuggle up to the marketing department or engineering or finance and learn their ways so we can create better systems that directly impact them? Or do we want to tend to a cloud provider’s server farms, work in datacenter infrastructure, provide SaaS or offer specialized consulting skills (security, ITIL, compliance auditing)?

The answer to those questions are largely personal and will reflect an individual’s personal preferences concerning what they like to do in their vocation.

Either way, it seems obvious that change is coming. Change that I wasn’t expecting just a year ago. Where you? Are you braced for it now or are you unconvinced? Take a look at the article and tell me what you think.

This has made for some unexpected decision making in my life.

A recent article at queue.acm.org piqued my interest. Titled “Overspecialization can be the kiss of death for sysadmins”, a budding SysAdmin asked “What is the biggest threat to systems administrators?”, specifically referring to the SysAdmin profession.

The answer was a 14 paragraph monologue that, in my interpretation, was very good advice but answered a completely different question. The answer boiled down to two points:

1. Work smarter, not harder
2. Communicate better with your bosses concerning what it is that you do all day

I think that is great advice for keeping your job today, but doesn’t seem to answer the bigger question that the budding SysAdmin asked concerning where the SysAdmin profession is going as a whole. Either that or I’m hyper-sensitive to this topic since I’ve been all abuzz about it in the last few months and I’m misinterpreting everything I read.

First, I’ll address the well meaning advice that was offered to the budding SysAdmin.

Point number one of the original article states that it should be a SysAdmin’s priority to strive to know what to do more than merely how to do something. You need to be a decision maker. Those that are merely grunt workers, churning out mod_rewrite rules on command or twiddling ACLs in the ASA are easily outsourced. Those that primarily decide why a rewrite rule is needful or what threats need to be mitigated at the gateway are the valuable ones. Double points if you do both. In fact, it is my opinion that the separation between decision makers and implementers is closing. due to cost and a greater potential for miscommunication.

The article also lumps overspecialization into it’s first point. Not only is it bad to stay comfortable with being told what to do rather than learning why to do something, it’s equally bad if you only know one thing very well. If demand for that thing goes away (and it always will, in some capacity), you’re left out in the cold. However, in my opinion, that’s merely a symptom of choosing to think about how to do something rather than why you should do something. It’s one thing to know everything about how to run a web farm using NCSA HTTPd. It’s a more valuable thing to know why you shouldn’t. Overspecializing is a symptom of not thinking hard enough.

The number two point in the article points out that even if you’re awesome at what you do, make great decisions and implement stunning examples of systems engineering perfection, if no one knows about it then it’s essentially useless to you and your department. That’s true enough. People need to know what you do so you can justify your budgets and positions. This isn’t about slimy self-preservation and self-promotion. This is professionalism. If you want your company to succeed, then they need to know what you do, why it should be done and how much it costs. If you communicate well with those around you, you will have less frustrations and more success. Fairly simple, but it’s a tried-and-true concept.

My argument is that this has nothing to do with the original question about the SysAdmin profession. Any professional in any field should be heeding this advice, which is great, but isn’t addressing the larger shifts in the profession towards outsourced and decentralized IT that are being seen.

A budding (or veteran) SysAdmin will probably be confused and angry if he defines his role well and communicates with his superiors, peers and users and yet still finds that his job at an internal IT department is hanging in the balance or changing into something that’s terribly foreign to him.

Well defined job roles and good communication are essential, but we’ll probably have to be doing this from within individual business units or from outside service providers.

I will give my own answer to the budding SysAdmin that asked a very good question: “What is the biggest threat to systems administrators […] as a profession?”

The biggest threat to Systems Administration as a profession is: Telepathic robot drones.

Seriously, until machines become sentient and can read the minds of the directors and executives of a company, I don’t think we’ll be obsolete. Our job is secure. However, don’t expect our roles to look the same in 10 years. Not even 5 years. I think there will be fewer specialized techs within corporate IT departments and more of them will cluster into service companies that provide their specialty with great precision.

I do not believe that all kinds of specialization are a fast track to obsolescence. If you focus on one solid thing (operative word being solid; COBOL is not solid), such as storage area networks, network security, Active Directory, you can develop along with the technology. You can watch trends and see the signs of change better as a specialist than as a generalist. From there, it’s a simple matter of choice to change with the times before you’re left in the dust.

Internal IT departments will become more mediators between the outsourced specialists and the needs of individual companies or business units. Internal IT people will take care of the company’s fragile, custom solutions or systems that are not trusted to outside providers such as databases with sensitive information.

In the end, as long as there are computers there will be SysAdmins. We may become a bit specialized and we might not have the same opportunities to work internally to a company, but we’re here to stay.

Oh, and the advice about working smart and communicating? That’s true for any profession whether you’re a plumber, welder or pogo stick designer.

And you? Are you specialized and worrying about obsolescence? Are you a generalist and feeling secure in your position? What do you believe about the future of systems administration?

(Edited May 26, 2010 for grammar)