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

The Enterprises of today (2015) have never been engineered. They happen... incrementally... over the life of the Enterprise as it grows and requires formalisms... "systems", manual and/or automated.  

Here are some samples of seminal works that constitute the origins of Enterprise Architecture:

The Information AgeHere is a little context around the Information Age. In the interest of time and space, I will try to be brief but there is a key point I have to make. Having made this observation, I will limit my comments about the Information Age to some well-known works by Alvin Toffler, and I will probably break this blog into three separate parts based on the following, so look for those shortly: 

In the third blog of three about "The Information Age," the third book Toffler wrote about change was "Powershift." The basic idea in this book is, if you give everyone the same information at the same time, the power will shift outboard. No longer will the power be concentrated in two or three people at the top who know everything, decide everything, control everything... the power will shift outboard. 

The second book Toffler wrote about change is "The Third Wave," and this is my 2nd in a series of three blogs. In this book he was contrasting the characteristics of the major "Waves" of humanity:

In the Agricultural Wave, the basic discipline of humanity was Farming.

Back to the Toyota illustration... now that Toyota has all these parts engineered to be assembled into any Toyota and have pre-fabricated them and have them in inventory before they get any orders... how does Toyota "cost-justify" those parts? They don't have any orders so there is no revenue. They are not making any money... they are not saving any money in the current accounting period. 

WOW! We have been Zachman Certifying so many people these last 2 months, I feel like I have been on the road non-stop! Sorry to take so long with this next part of the blog!

Go back to the Toyota illustration... I want to develop a pattern, a Strategy Pattern, for you. I am sure it is a universal pattern. I use Manufacturing, tangible products, because they are easier to conceptualize than intangible products like services but I am sure this is a universal pattern

Initially, the customer is willing to accept these limitations... they don't know any better. But, over long periods of time, 50 or a hundred years, they get frustrated and the drive the manufacturer out of a Job Shop into a Standard Production Environment (mass production) in order to solve the problems. Actually, the problem is the strategy. 

My goodness! Cort and I have been teaching non-stop! We have Zachman Certified just over 65 people in the last month!

OK, on with this blog...

Clearly, you have to change the strategy... to an Assemble-to-Order strategy... Mass-Customization, "custom products, mass-produced in quantities of one for immediate delivery"... but this is a completely different kind of a business.

My goodness! I'm so sorry to take so long with another blog! I'll bet this year is the most people we have Zachman Certified ever! HUNDREDS of folks this year so far!

In the Information Age, the characteristics we understand to date are complexity and change. The customer wants a product specific to his or her specification... a custom product. The customer is a market of one. And, the customer may not even know what they want until they want it and then they want it now... immediately. And, if you can't produce to those requirements, click! 

Architecture: AbstractionsYou can classify the set descriptive representations of anything (buildings, airplanes, locomotives, battleships, computers, etc.) in a two dimensional classification structure, a "schema". 

Architecture is a SET of Descriptive Representations.

I the object you are trying to create is simple, you can see the whole thing at the level of definition required to create it ... like a log cabin ... or a computer program ... you don't need Architecture. All you need is a tool, like an axe of a compiler or something and some raw material like a forest, or some data or something, and some time, then build log cabins or write computer programs.

I think before we can define Enterprise Architecture, we need to ask ourselves the first question: "what is Architecture?"

Architecture ... what is it?

Some people think the Roman Coliseum is Architecture. This is a COMMON MISCONCEPTION!

Notice: This same mis-conception about Enterprises is what leads people to misconstrue Enterprise Architecture as being big, monolithic, static, inflexible and unachievable ... and it takes too long and costs too much!

I'd like to put some posts together about what I think "The New Paradigm" for Enterprise Architecture is. I will break this up into 5 or 6 blogs that deal with this in terms of Enterprise Architecture expenses vs. assets, cost justification of Enterprise Architecture, providing from stock vs assemble-to-order strategies, mass-customization of EA and some cultural implications of this new paradigm.