Defining Enterprise Architecture: Economics and the Role of I.T.

So, why is it that an Enterprise needs Information Technology people in their Enterprise in the Information Age?

When I happen to be talking to some IT folks and I raise the question, "Why does the Enterprise need Information Technology people in their Enterprise in the Information Age?" I usually warn them at this point that I haven't had an hour and a half or so to soften them up and I am going to make a radical comment... so don't fall of their chairs when I say this but...

"If you think the Enterprise sends you a paycheck every couple of weeks or so because you are building and running systems, I have some friendly advice for you... there is a cloud in your future! It (IT) is going outboard!"

I spoke at a conference in Orlando several years ago and Nicholas Carr was talking at the same conference. You might recognize his name. He is a Harvard Business School professor that wrote that article in Harvard Business Review "IT Doesn't Matter" making all of the IT folks really upset. He was talking at this rather large IT conference and he was proving one more time that "IT Doesn't Matter"... and he had a LOT of data to prove it. And, the data he was using was economic data.

Basically, what he was saying is, it doesn't make any economic sense to have your own internal IT community to build your systems for you and it doesn't make any economic sense to have your own internal IT infrastructure to run your systems either. When he wrote the original HBR article about 12 years ago he was talking about building the systems. At this conference, he was talking about the "Cloud", running the systems. And, he has written several books on the subject in the intervening years.

The conference was made up largely of technology management folks as well as quite a few academic folks and he was still making many people upset. However, I think Nicholas Carr is right! The economics legislate, IT is going outboard.

However, I have been in the IT domain for about 50 years so I am not naive about it. You can't just put your brain in neutral and outsource everything and expect everybody to live happily ever after!

If you are going to outsource the building of your systems to someone else, you'd better have the ability to articulate precisely what you have in mind for them to build for you or else you are going to get back from them whatever they build... which is not too dissimilar from what Management is presently getting from their internal IT community.

I spoke to a military strategy group several years ago and there was a security expert who was billed as the foremost security expert the world has ever seen... and, I was impressed... he fit that billing!! He was making the case that the security problems we have experienced up until that time were typically from college kids who didn't have anything else to do but prove they were smarter than you by breaking into your systems. However, from now on, the problems will be coming from organized crime... people who either want to steal your money or destroy your Enterprise and the proven device they will use is subterfuge. Then he said... "how do you feel about your software being built by your mortal enemies?" Gulp! My observation is, if you are going to outsource building your systems, you better have the technical ability to define precisely what it is you want to have built and then ability to examine what you get back to make sure that what you got back is what you ordered.

In terms of outsourcing the running of your systems to a Cloud... it is my understanding from a very credible academic friend that 80% of the intellectual property of the United States has already been compromised. If you put something out on a Cloud someplace, you are saying, "okay you guys, here's the other 20%!" You are just making it easier. I am not saying "don't do it". I am just saying that if you are going to put something out on a "cloud", you'd better understand what you are doing. Maybe the network security on the Cloud is better than the network security you can provide for yourself... and I am sure the security in general is going to get better. However, none the less, you'd better think it through and know what you are doing.

Yes, I think Nicholas Carr is right... the economics legislate that IT is going outboard. However, all the management responsibilities don't go away... you still have all the scheduling, budgeting the project management, etc. in addition to defining, validating, and securing.

In any case, assuming for a moment, the bulk of IT is going outboard, why would an Enterprise need IT people in the Information Age? That is, what do IT people bring to the table to an Enterprise in the Information Age?

I submit, IT people bring to the table the drafting skills... the drafting skills! They know how to describe things. They know how to build models. This is non-trivial! You send a mechanical engineer to a university... not to trade school... to university for four years to learn how to do drafting... to learn how to describe things so every other mechanical engineer in the universe can understand precisely what it is they are describing.

Is this an important idea?

This is a REALLY important idea. If you have more than one mechanical engineer working on that Boeing 747 (or hundred story building, or super computer, or locomotive, or semi truck and trailer, etc.) they all have to be reading off of the same page. If they are not reading of of the same page, you are not going to get a Boeing 747 or whatever it is you are building.

If you want the mechanical engineer to actually design something... that is two more years at the university... graduate school, a masters degree. They have to specialize... there will be mechanical engineers, aeronautical engineers, hydraulic engineers, pneumatic engineers, metallurgical engineers, electrical engineers, a bunch of engineers because one engineer doesn't know everything. One engineer doesn't engineer the entire Boeing 747.

I submit, Enterprises are FAR more complex than Boeing 747's, hundred story buildings or whatever other complex object you can conceive of. And, the Enterprise doesn't have to be all that big to be extremely complex! It is not realistic to expect one Enterprise Architect to engineer the entire Enterprise. There is a LOT of room for specialization. We don't see much specialization in Enterprise Architecture today but before we get done in this book, I will be able to speculate about the different engineering skills that are likely required for engineering Enterprises.

Back to the mechanical engineers... if you want the mechanical engineer to engineer something you don't mind flying on at night over water... that is about 25 years of apprenticeship because you can actually design things that don't work! How do you learn what works and what doesn't work? You don't learn that in school. You learn that on the job. You have to live long enough and fail often enough to learn what works and what doesn't work. "Hey!! Don't design it that way because we already know that is not going to work!"

You don't find people fresh out of universities with a bachelor's degree in Information Systems or Information Technology or Computer Science or anything else, for that matter, interested in Enterprise Architecture! They still think the solution to the world's problems lies in Visual Basic... or Agile Programming... or the Cloud! I am not saying there is anything wrong with Visual Basic or Agile Programming or any other programming language or methodology for that matter, or with the Cloud. But... I am saying "you have to live long enough and fail enough to figure out that writing a few more lines of code is not going to fix the Enterprise's problems."

So, why does an Enterprise need Information people in their Enterprise in the Information Age? They bring to the table the skills required to create the engineering design artifacts required to actually engineer the Enterprise!