Dynamically updating CSS Style attributes

Just having a little fun with CSS style attributes and came up with a demo page to demonstrate javascript dynamically changing the attributes of some text on the screen.

Click here to see.

The javascript/CSS that makes this happens is:

var DHTML = (document.getElementById || document.all || document.layers);

if (!DHTML) return;
var x = new getObj('divtext');

document.getElementById('divtext').innerHTML = text;
x.style.fontSize = fontsize;
x.style.color = color;
x.style.fontFamily = fontfamily;
x.style.fontStyle = fontstyle;
x.style.fontWeight = fontweight;
x.style.backgroundColor = backgroundcolor;

}

function getObj(name)
{
if (document.getElementById)
{
this.obj = document.getElementById(name);
this.style = document.getElementById(name).style;
}
else if (document.all)
{
this.obj = document.all[name];
this.style = document.all[name].style;
}
else if (document.layers)
{
this.obj = document.layers[name];
this.style = document.layers[name];
}
}




A little break from SOA and EA Frameworks :-)

Enterprise Architecture Definitions

As there are numerous definitions of SOA, there are also numerous definitions of Enterprise Architecture. Like with SOA, one may derive a definition of EA from reading between some of the definitions provided in many of the popular EA/SOA books


From these definitions, I get the idea that Enterprise Architecture is:

The current definition of an enterprise's business processes and the information technologies that aid in their execution. The Enterprise Architecture is a dynamic form of documentation which is subject to change in the short and long term due to changes in both business and technology. EA is a road map for the Enterprise concerning business process and technology to make IT a strategic asset.

Two of the main EA Frameworks I have looked at deal with it in different ways. The Zachman Framework seeks to classify the Enterprise by mapping Enterprise components into one of 36 classification squares. TOGAF presents an ADM(Architectural Development Cycle) which is an iterative cycle of how to define the Enterprise Architecture.


The definitions below are taken from my research in to SOA and Enterprise Architecture. I do not think it coincidence that so many of the SOA books mention Enterprise Architecture. They do complement one another. Maybe one could say that SOA is a style of architecture to help make Enterprise Architecture better. Or maybe Enterprise Architecture can tell the enterprise what to build with SOA. The two concepts are apparently strongly linked.

On Todd Biske's blog, he mentions a quote from David Linthicum on SOA and EA.

"Five years from now, we won’t be talking about SOA… It will all be folded back into EA." - David Linthicum


Enterprise Architecture Definitions:

“The enterprise architecture is the organizing logic for business processes and IT infrastructure, reflecting the integration and standardization requirements for the company’s operating model. The enterprise architecture provides a long-term view of a company’s processes, systems, and technologies so that individual projects can build capabilities – not just fulfill immediate needs”1

“In simple terms, an Enterprise architecture identifies the main components of the organization and the ways in which these components work together in order to deliver the product and achieve the business objectives at the same time”.2


“You must recognize that the enterprise architecture is not static – it is constantly changing as business needs vary and technologies evolve. The task of the enterprise architecture group is to guide this evolution. To do so requires that the group keep one eye looking toward the future and the other focused on the realities of the present, while continually striving to draw the two together. Managing this evolution requires understanding the current state, articulating a vision for the future, and defining a roadmap for getting from here to there”3


“Enterprise Architecture is basically a discipline of IT architecture where we are concerned with IT in the context of the company as a whole – both IT and business”4

“An architecture description is a formal description of an information system, organized in a way that supports reasoning about the structural properties of the system. It defines the components or building blocks that make up the overall information system, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. It thus enables you to manage your overall IT investment in a way that meets the needs of your business.”5

“An enterprise architecture specification is to an organization what an urban plan is to a city. Therefore, the relationship between an urban plan and the blueprint of a building are comparable to that of enterprise and application architecture specifications.” 6


References:
1.Ross, Weill, Robertson,”Enterprise Architecture As Strategy”, 2006, p. 9
2.Grigoriu, “An Enterprise Architecture Development Framework”, 2006, p.22
3.Brown, “Succeeding with SOA”, 2007, p 115-116
4.Bloomberg,Schmelzer, “Service Orient or Be Doomed!”, p.121
5.The Open Group, TOGAF The Open Group Architecture Framework 2006 Edition
6.Thomas Erl,”Service-Oriented Architecture(Concepts, Technology, and Design)”, 2006, p. 87

My Definition of SOA and others

I have been reading on SOA for just over a year now and am feeling more comfortable with it. I know that SOA is not the same thing as web services although web services is probably the most commonly used technology, although SOA has been implemented in other technologies including CORBA.

My first crack at the definition of Service Oriented Architecture:

An SOA is an architecture consisting of reusable interoperable services to help make the enterprise more agile(reducing time to market) and efficient(increasing component reuse). Services should be discoverable, composable, provide an SLA and adequate security. An SOA is aided greatly by the use of an Enterprise Service Bus(ESB). The ESB acts as an intermediary between the service consumer and service provider. The ESB allows the service consumer and service provider to interact without knowing the location of the other, essentially avoiding any point to point integration problems.

I welcome other viewpoints on the definition of SOA, please comment if you have other ideas or agree more with one of the defintions listed below. Although, I think there is no true correct definition.

Antony Kimber has a posting on the definition of SOA as well at http://soaevolution.blogspot.com/2007/09/definitive-soa.html.

My eventual goal is to look at the benefits of Enterprise Architecture Frameworks in implementing an SOA. In particular, TOGAF and the Zachman Framework.


The following is a list of 9 SOA definitions from recent popular books on the subject or vendor websites:

“SOA is a form of technology architecture that adheres to the principles of service-orientation. When realized through the Web services technology platform, SOA establishes the potential to support and promote these principles throughout the business process and automation domains of an enterprise.” 1

“With an enterprise architecture grounded in Service Orientation, we’re looking for a broad set of rules and practices that govern the design and evolution of organizations that leverage business resources as Services. We call that set of rules and practices Service-Oriented Architecture”2

“SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. “Services” in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.”3

“SOA is neither a technology nor a technology standard, but instead it represents a technology-independent, high-level concept that provides architectural blueprints, such as the ones outlined in the first part of this book. These architectural blueprints are focusing on the slicing, dicing, and composition of the enterprise application layer in a way that the components that are created and exposed as services in the SOA are not only technically independent but also have a direct relationship to business functionality”4

“SOA is supposed to provide clean, well-defined interfaces between business entitites – between service providers and service consumers”5

“Service-Oriented Architecture (SOA) is an architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.”6

“Service Oriented Architecture (SOA) is an architectural design pattern that concerns itself with defining loosely-coupled relationships between producers and consumers.
.. There is no widely agreed upon definition of SOA other than its literal translation. It is an architecture that relies on service-orientation as its fundamental design principle. In an SOA environment independent services can be accessed without knowledge of their underlying platform implementation. These concepts can be applied to business, software and other types of producer/consumer systems.
”7

“Service orientation is a means for integrating across diverse systems. Each IT resource, whether an application, system, or trading partner, can be accessed as a service.”8

“Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. SOA helps users build composite applications, which are applications that draw upon functionality from multiple sources within and beyond the enterprise to support horizontal business processes.”9

References:

1. Thomas Erl,”Service-Oriented Architecture(Concepts, Technology, and Design)”, 2006, p. 55
2. Bloomberg, Schmelzer, “ Service Orient or Be Doomed”, 2006, p.126
3. Marks, Bell, “Service-Oriented Architecture – A Planning and Implementation Guide for Business and Technology”, 2006, p.1
4. Krafzig, Banke, Slama “Enterprise SOA – Service Oriented Architecture Best Practices”, 2005, p. 8
5. Brown, “Succeeding with SOA”, 2007, p xxii
6.https://www.opengroup.org/projects/soa/ ,Retrieved October 28, 2007
7.http://en.wikipedia.org/wiki/Service-oriented_architecture, retrieved October 28, 2007
8.http://www.microsoft.com/biztalk/solutions/soa/overview.mspx#EFBRetrieved October 28, 2007
9.http://www-306.ibm.com/software/solutions/soa/ Retrieved October 28, 2007

Enterprise Architecture As Strategy

Seeking further knowledge in Enterprise Architecture led me to read "Enterprise Architecture As Strategy" by Jeanne W. Ross, Peter Weill, and David C. Robertson. It seems that just as with SOA, EA lacks consistent definitions but this book provided some interesting business examples of how EA really can help your organizations.

They define enterprise architecture as "the organizing logic for core business processes and IT infrastructure reflecting the standardization and integration of a company's operating model". This boils down to 2 concepts: business process integration and business process standardization.

There are 4 types of operating models defined in regards to classifying companies:

1. Diversification (low standardization, low integration)
2. Coordination (low standardization, high integration)
3. Replication (high standardization, low integration)
4. Unification (high standardization, high integration)

The operating model represents a general vision of how a company will enable and execute strategies. Focusing on the operating model rather than on individual business strategies gives a company better guidance for developing IT and business process capabilities.


There are some real interesting case studies on how some successful companies like Seven Eleven Japan, CEMEX and UPS truly exploited their IT infrastructure to succeed in the marketplace. It is all about digitizing the core business processes.

Four stages of architecture maturity are defined:
1. Business Silos architecture - maximize individual business unit needs
2. Standardized Technology architecture - providing IT efficiencies through technology standardization and, in most cases, increased centralization of technology management
3. Optimized Core architecture - company wide data and process standardization to company model
4. Business Modularity architecture - manage and reuse loosely coupled IT-enabled business process components to preserve global standards while enabling local differences

Four strategic outcomes from enterprise architecture

1. Better operational excellence - low-cost, reliable and predictable operations
2. More customer intimacy - extraordinary customer service, responsiveness based on deep customer knowledge
3. Greater product leadership - first to market with innovative products and services
4. More strategic agility - respond rapidly to competitor initiatives and new market opportunities

They also mention to build the foundation one project at a time which must meet the short-term business goals and at the same time implementing or at least not undermining the company's architecture. (This was a point in Brown's "Succeeding with SOA") The goal is to have the enterprise architecture as a compass, directing the company toward its intended operating model. The IT Architecture should be viewed as an asset and not a cost.

Succeeding with SOA

I just finished reading Paul C. Brown's "Succeeding with SOA - Realizing Business Value Through Total Architecture". The book describes how to approach SOA from the business side focusing on value and organization rather than technology.

He outlines 4 keys to staying on track with the total architecture approach to SOA:
1. justify each project on its own business merits
2. have an explicit architecture step in every SOA project that precedes the actual development work
3. have an active SOA architecture group
4. have a living SOA project roadmap

I liked the idea that every SOA project must have it's own definite business merits as to continually supporting the SOA movement. The positioning of the Architecture group among the business silos in an effective way is discussed.

As far as SOA Project Leadership goes, there are 3 critical project leadership roles.

1. Project Manager - responsible for ensuring that the combined business process and systems changes actually generate the project's expected business benefits within the cost and schedule guidelines

2. Business Process Architect - determines the structure and organization of the overall business process

3. Systems Architect - determines the structure and organization of the information systems supporting the business processes


Brown really emphasizes the architecture of business processes along with system architecture. This really makes sense as SOA is about mapping services of the enterprise.

The Total Architecture Synthesis(TAS) is an approach to developing business processes and systems together. "When compared with the classic waterfall-style development, this approach significantly reduces project cost, time, and risk. When compared with agile programming, this approach validates architecture suitability before committing to implementation" This process leverages the use of standard UML(Unified Modeling Language) design notations to capture the design of both business processes and systems. The use of UML is a good idea, as I feel that having a well known tool for capturing information is desirable.

All in all, a common sense book and I look forward to the forthcoming book, "SOA in Practice". This accompanying book will be more aimed at SOA Architects, rather than the focus on Enterprise leadership of this book.

Enterprise Architecture and SOA

I am trying to scour for articles on Enterprise Architecture and SOA. Here is an article explaining how the relationship between EA & SOA.

The April 2007 edition on the IASA's Perspectives of the IASA "Special Issue: Enterprise Architecture - A 20 Year Retrospective"

"Enterprise Architecture and SOA: A Partnership" by Dr. Yan Zhao

There is also an interview with John Zachman, creator of the Zachman Framework.

The link to this article here

Please let me know of your opinions on EA framworks and their application to an SOA implementation. I am trying to focus more on the Zachman and TOGAF EA frameworks.

Zachman Framework Parts 5 & 6 - The Metaframeworks and Conclusion

I have finally finished reading the Zachman Framework eBook and it is interesting and will take some more time to absorb!

Part 5 – The Metaframework

Chapter 12 - Introduction

Some people may be tempted to skip Part5: Meta and the Framework because it is discussing meta concepts and at the very mention of the word meta some people begin to get dizzy.

The model of any one Cell (the Cell metamodel) would depict the internal structure of all the occurrences of the one columnar variable from the perspective (audience) for which the model was constructed. The basic, simple meta entities for each Cell appear in the Framework graphic at the bottom of each Cell. For example, in Column 1, Row 2.

A number of standards groups are attempting to define standard metamodels for a number of the Cells, predominantly in Row 5 (whether they are aware that they are defining standard metamodels for Row 5 of the Zachman Framework, including the OMG, the MDC, the OSI, etc, etc.

Actually, I am not too embarrassed to admit that we do not have a standard metamodel of all the Cells in 2002. At least we have a pretty good understanding of what each Row is describing and what each Column is describing and therefore, what the essential contents are for each Cell. That may be all that is needed to get started.

But GOOD NIGHT!! This is the most complex engineering and manufacturing problem known to mankind, ENTERPRISE Engineering and Manufacturing, and this Enterprise Engineering and Manufacturing discipline is only about 50 years old!!

All repositories and some modeling tools have extensible metamodels, that is, they make it easy to extend their database design (or, change their semantic structures, that is, change the meaning of the metadata) to accommodate a specific metamodel for a specific Information Systems Enterprise.

Chapter 13 – Metaframeworks

The Enterprise Engineering and Manufacturing Framework models at Row 2 are meta relative to the Enterprise Framework.

This is exactly the same relationship that the Enterprise Framework has with its Product Framework. Every product has a set of models (a Framework) that are descriptive of the product. That’s where I learned about the Framework to begin with… I was looking at the descriptive representations (design artifacts) for airplanes, buildings, locomotives, computers, automobiles … complex engineering products.

CAUTION: Services of the Enterprise are different from Products in that Service does not exist independently of the Enterprise itself. Services, if they are sufficiently complex, may be considered to have a Framework of their own to help define and specify them, but if this is helpful, the Service Framework must be merged into (that is, integrated with) the Enterprise Framework or you will end up with a dis-integrated, Service stovepipe or a frustrating legacy of Services just like we have a frustrating legacy of applications today.

Chapter 14 – Knowledge Domains
In the discussion of metaframeworks, I have described three domains of knowledge that are increasingly critical to the on-going management of a modern, Information Age Enterprise:
1. Knowledge of the Product of the Enterprise,
2. Knowledge of the Enterprise itself and
3. Knowledge of the Enterprise (i.e. Information Systems et al) that is engineering and manufacturing THE Enterprise (EE&M)


Chapter 15 – Multiple Frameworks in the Same Enterprise
.. you could apply the Framework logic to every single business unit on a stand-alone basis. Enterprise-wide would mena Business Unit-wide and the analysis would likely be more manageable. The Business Unit Frameworks could potentially be integrated into one bigger Enterprise Framework. It is only a matter of how you graphically want to depict them.

You don’t get integration by accident. If you WANT integration, then you have to ENGINEER for integration. That means that you will have to DICTATE to the Business Units that you want such and such slivers of such and such Cells of their Frameworks to all be THE SAME.

In the Information Age, there is significant management advantage to knowing, having coherent visibility into the Enterprise and its environment. Change(maneuverability) is the dominant strategy option. The Enterprise that is optimized, knows sooner and can destabilize the market is the one that wins the game. These are the bnefits of integration. This is the reason why the definition of Enterprise is important to management.

The Framework is inert. It does not know what you are using it to think about. Only the analyst, or engineer determines what the analytical target is. It can be used to classify the descriptive representations of anything.

All of these characteristics of the Framework make it a good thinking tool … a thinking tool that will help thinking about a very complex subject like an Enterprise. Once we establish an analytical target, we can think about one thing (one Cell) at a time without losing sense of its Enterprise (Row and Column ) context. We can isolate a single variable and think about that Cell without getting mired down in the myriad of issues going on in the other 35 Cells. At the same time, we can maintain an awareness of thither related, peer, meta or granular Frameworks. We can think about slivers of Cells, vertical or horizontal slivers, and see the short term and long term implications of implementation strategies.

Part 6 – In Conclusion

Chapter 16 – Cheaper and Faster

How do you cost-justify Architecture?
The obvious answer to the question is, you can’t cost-justify Architecture because cost-justification is an expense-based concept and Architecture is not an expense. Architecture is an ASSET.

An example is given from one of the eastern states in the early 90’s

-The cost per new entity type/RDBMS table was reduced from something greater than $150,000 per table to something less than $10,000 per table (That’s a 15 times improvement … not too shabby.)
- Enterprise data handling labor reduced by 50%
- Reduced development time of 25% through improved communication and conflict resolutions
- Development time and cost reductions for every succeeding implementation of 50% compounded through reuse of database and application components with no modifications.(Actually, the exact quote was, every time we reuse something we get 100% return on our investment.)
- Reduced disk space for data(including history) of 20% - %80 through elimination of redundancy

A better way to ask the question how do you cost-justify architecture? Would be, where do you get the up-front money to do Enterprise Architecture?
Answer: You don’t need up-front money!!! Just go get the money they are already spending or about to spend and instead of dribbling it away writing code and implementing, use it judiciously and do some engineering(Architecture) first, before you start manufacturing(implementing).

Zachman Framework Part 4 - Frustration, Segmentation, and Migration

Here is more summary notes from the Zachman eBook. It is pretty interesting.

Chapter 9 – Frustration

In fact, it is a miracle that anything got implemented that had anything to do with what the Owners had in mind when we never defined what they had in mind in the first place. In contrast, the Row 6 implementations are locked in concrete.

The solution to this problem is to begin to see that the models are not simply a convenience for helping to build the systems. No! They are the equivalent to the Product Definition of a complex product, for example, they are like the drawings, functional specs, bills-of-material, etc., etc. for an airplane.

Summarization Column by Column the issue and degree of frustration:

Column 1: Things (the date being surrogates for the Things) – if you have redundancies and discontinuities in the data, you have a Tower of Babel problem. You are unable to communicate effectively or take inventories and analyze the asset consumption and utilization an you will lose control of the business.

Column2. Process – the same process is replicated and not being performed consistently. This is not very efficient but it won’t bring the Enterprise to a screeching halt.

Column 3 – Location – the distribution of the Enterprise as manifest in the hardware/systems software. You could have every kind of hardware/systems software known to mankind. The stability of the network deteriorates and the cost of keeping the network up 24x7 is running somewhere around 50% of the Information Systems budget.

Column 4 – People – the work flow is disintegrated… every user has a plethora of screens customized for every different application they use. This is not very efficient but it won’t bring you to a screeching halt.

Column 5 – Time – there is no coherence in the dynamic aspects of the Enterprise. I know little about this column of models but the more I understand about Industrial Dynamics, the more I suspect this is having a substantial although unrecognized impact on the Enterprise

Column 6 – Motivation – it is from here that the business rules are derived and if the same business rule is imbedded inconsistently or incoherently in multiple system, management is going to be really frustrated.


There are 3 columns of models that will cause substantial management frustration if there are inconsistencies or incoherencies across the scope of the Enterprise. They are Column 1 (the Thing Column as it is manifest in the data), Column 3(the Location Column as it is manifest in the hardware/system software) and Column 6 ( the Motivation Column as it is manifest in the business rules).


The Key is Column 1. If you can figure out how to build out Column 1 , the Thing Column, sliver by sliver, everything else will fall into place for you.

Chapter 10 – Segmentation


Promoting to Enterprise-wide Quality – Some of the Entities in the Enterprise-wide Data Model they left at only “project quality.” That is, they didn’t make any effort to acquire any agreement by any other users as to their structure..

Chapter 11 – Migration
You could build out of the Semantic Model (Column1, Row2) to 200-300 Entities, run the where used application, define the build sequence based on data dependency, pick up some slivers to flesh out in detail, transform the high level of detail Semantic Model(Row 2) to a high level of detail Logical Data Model (Row3) and build out the Logical Data Model(Row3) sliver by sliver at excruciating level of detail in dependency sequence.

Before the Enterprise would be able to perceive any practical value from the Data Model, you would have to transform it to Data Design(Row4), transform that to Data Definition(Row 5) and create the resultant database (Row 6).

Data Warehouse

If you can populate the Architected database with data from the legacy files that has consistent meaning and good quality, you can make a lot of management folks very happy reasonably quickly. The data will look integrated to them.

The Genius of Data Warehouse

- You move the output processing into an architected environment without having to rebuild all of the input processing systems…give management access to integrated appearing data with a limited amount of work, which likely makes them VERY happy(for a change)
- You set up a 3 schema environment and reduce the change liability from a geometric function(m x n) to an arithmetic function(m+n)

Technology Architecture

The same basic concept could be used for migrating out of the legacy Technology environment that is, define the to be, normalized, standard hardware and systems software Column 3, Row 4 Technology Architecture. Then rebuild the applications one at a time, moving them from the legacy environment to the Architected environment. In this fashion, you could leverage the value of the legacy up until you shift the dependency, system by system, to the new environment. This gives you time to stabilize each conversion before embarking of the next.


Process, Work Flow, Business Rules and Dynamics Architectures

Once you begin the migration to the architected environment and begin to diffuse some of the Enterprise’s frustrations relative to the Legacy in Column 1 (Data), Column 3(Technology) and Column 6(Business Rules), it will buy you some time to examine the Enterprise Processes(Column 2) and Work Flow(Column 4) with regard to possible normalization. This would provide marked improvements in efficiency and establish a baseline for facilitating process and work flow change.

In Summary on Part 4 Frustrations

The pain level in if not most Enterprises has become increasingly intense as we continue into the Information Age, and I have suggested that the cause of the pain lies in our historical lack of understanding and employment of architectural concepts in our Enterprises, particularly in Column 1, and Column 3, and Column 6.

Review of Zachman Framework Parts 2 & 3

I have been trying to quickly absorb the Zachman Framework and the following are excerpts from the Zachman eBook.

Chapter 4 – Observations in Physics

The implications of having no Architecture are that once the assumptions start to change, it is extremely difficult, extremely time consuming to attempt to reverse engineer the assumptions (the Enterprise models) out of the existing systems, change them and reconstruct new implementations.

All those models identified by the Framework are always present. It is only a matter of whether you make them explicit or not.

The System is the Enterprise

Vertical Slivers
It is okay to build slivers of Cells, but if you want the slivers to be integrated (reusable, normalized, seamless, interchangeable, interoperable, etc., etc) you have to do something over and above just building a bunch of slivers.
Columns 1(the Data Column) ,3 (the Network Column), and 6(the Motivation Column) are the three columns that the Enterprise finds critical for scope(Enterprise-wide) integration.

In Summary of Enterprise Physics

First, all the models are always present. It’s only a matter of whether you make them explicit or not. If you don’t make them explicit, they are implicit which means you are making assumptions about them.

Second, the system is the Enterprise. Manual systems employ pencils, paper and file cabinets. Automated systems employ stored programming devices and electronic media.

Third, high level of detail descriptions (models) are good for planning, scoping, bounding, segmenting, etc. (High level descriptions are no good for implementation)

Fourth, narrow in scope descriptions (slivers of models) are quick. (Narrow in scope descriptions result in stovepipes)

Note: if you start thinking your Enterprise is exempt from these physical principles, I assure you, you are vulnerable to experiencing pain.

Chapter 5 – End State Vision

Change with minimum time, disruption and cost is dependent upon Architecture.
If you have no Architecture, there is NO WAY you are going to change anything with minimum time, distuption and cost.

The Methodology Message
- Build Models
- Store Models
- Manage (Enforce) Models
- Change Models

I am suggesting that the norm has to become the models and the exception has to be you start writing the code.

First, I am NOT saying, forget about short-term demand!
I am NOT saying: Never take the short-term option! Sometimes, because of the business exigencies, you are going to have to go directly to you start writing code…! There is nothing the matter with short-term options… as long as you recognize they are short-term options.

It should be an Enterprise decision whether to take the short-term option or the long-term option, not an information systems(or, technical) decision.


Part 3 – End State Vision
Chapter 6 – Introduction to Engineering Design Objectives

Design objectives include flexibility, adaptability, alignment, and quality
These only come by engineering… Enterprise Engineering

Reducing Time-to-Market

Make-to-Order
Shifting to an assemble-to-order environment. That is, the culture of the assemble-to-order (mass customization) environment is diametrically opposed to he make-to-order (job shop) environment.

The only way you are going to be able to reduce time-to-market to virtually zero is to Engineer and pre-fabricate the parts in the inventory such that they can be assembled into more than one product, that is, be reused in more than one implementation.
By the way, if you DO NOT have something in inventory before you get the order, you ARE a job shop, that is, in information systems terms, a waterfall.

Any Cell (primitive model) of the Framework is a candidate for engineering for reusability.

Chapter 7 – Additional Engineering Design Objectives

If you REALLY want the implemented Enterprise to align with what the Owners have in mind, you ARE going to take a top, down approach for building it out.

In summary on flexibility, change with minimum time, disruption and cost, there are several basic ideas:
-Separate the independent variables so you can change one variable
-Insert a conceptual schema (intersection) between many-to-many variables to reduce change liability from geometric to arithmetic
- Work with normalized, primitive models so you can change any concept once and it is changed for every employment
- Retain all primitive models to serve as a baseline for managing change (Someday, you are going to wish you had all those models… because I am equally convinced that the primitive models constitute the engineering basics!)

Chapter 8 – The Value Proposition for Architecture

Enterprise Architecture is an asset, not an expense. Architecture is a long term strategy. The basic idea is, you do the engineering before you start manufacturing in order to eliminate, minimize, or at least reduce the scrap and rework costs. You are investing in an inventory of assets that can be used(reused) in more than one implementation.

4 things you are unable to do in the Enterprise unless you invest in Architecture, an inventory of primitives engineered for reuse
- Alignment(quality). To ensure that the Enterprise implementations are consistent with the Owner’s intentions
- Integration(seamlessness, interoperability, standard interchangeable parts). To eliminate redundancy, duplication, discontinuity, incoherence, etc.
- Change (flexibility, adaptability). To change the Enterprise with minimum time, disruption and cost.
- Reduced time-to-market. Architecture coupled with an assemble-to-order strategy to reduce the time it takes to produce implementations to only the time it takes to assemble.


Part 2 – Analyzing the Enterprise

Good to Great

I recently borrowed this book off of one of the executives at work. I am hoping this is the one of the few reads I will do unrelated to my Thesis until it is done. I would like to summarize some of the important points to help reinforce what I read.

Basically, Jim Collins studied numerous companies and tried to distill what 11 companies out of thousands did right which lead to their exceptional growth and value creation.

Level 5 Leaders - Builds enduring greatness through a paradoxical blen of personal humility and professional will.
I liked the comment about the window and the mirror. Look through the window when there is credit to be given and the mirror when blame is to be assigned.

The HedgeHog Concept - Do the simple things and do them well. Take the three circles (What you are deeply passionate about, What you can be the best in the world at, and What drives your economic engine) and your strategy should be within the intersection of these circles.


The Flywheel - Things do not happen in one fell swoop or some rah -rah session. It is a sustainable drive, like pushing on a giant, heavy flywheel, it takes a lot of effort to get the thing moving at all, but with persistent pushing in a consistent direction over a long period of time. (Sam Walton took 7 years before he opened his second store! from which came over 3000 stores and over $150 billion in revenues in 2000).

Read the book for more in depth, but I saw a documentary on it and its application to the public sector as well.