.:: dotNFS Blog ::.  

We will continue this writing from the 22 Jul 07, blog article entitled “Enterprise Architecture (EA) – Achievement is not automatic. “ The focal point of this article is “the what” of the Enterprise Architecture.

The “What” of the Architecture
Designing enterprise architectures means managing transformation and governance in an organization by means of encompassing the disciplines constructed of the models and principals of the vision. With that stated preferences must be made in concern of the depth and form of the architectures.

Can you answer within your organization “what” types of architectures are established? Most organizations do not have any formal form of any type of architectures. Yet they [architectures] exist at some form in all organizations.

Architectures are designed to provide governance and frameworks that steer the organizational information, applications, processes, and infrastructure.

With that stated the architectures would be design to encompass the organizational value chain, planning, products and services development, and resources based on the written vision document of the enterprise.

The frameworks of the architecture represent a two dimensional view of the aspects and forms that will be constructed.

Developing Effective Architectures

In developing the architectures, the organization must first identify the required changes needed. A section of the vision document should have specific strategic goals defined for the enterprise.  The architectures should be developed with the current needs written within the vision document and future changes feed back from the BPM methodology construct.

Executive management involvement is essential and key to architecture buy in. Without top management lead and support the architecture(s) will definitely fail to serve the organization.

Many organizations have attempted to implement enterprise architecture. It takes a dedicated and discipline organization to successfully implement an architecture of any type.  The success of the architecture is driven from top-down, lives, and is managed at the executive management level of an organization.

Contact dotNet Framework Solutions for your Enterprise Architecture consultation

We will continue this writing from the 22 Jul 07, blog article entitled “Enterprise Architecture (EA) – Achievement is not automatic. “ The focal point of this article is the vision of the Enterprise Architecture. 

An enterprise architectural Vision bestows the foundation Most enterprises are consumed with the functionality and services of their IT architecture and it is not a clear answer to why. The primary reasoning of this phenomenal occurrence is the advisement of IT management of greater efficient or effective operations to the enterprise.  This may be an honorable effort to insure added value and profitability to the enterprise but there is no underling (foundation) definition to support the philosophy. This philosophy of [efficient or effective] operations is a vague abstraction to providing a true picture of where the enterprise “is,” “what” is the desired goals, “why” it desires to accomplish these goals, and “how” will it achieve the desire goals.

The Enterprise Architectural Plan (EAP) is detached from the primary processes of the enterprise. The EAP governance ensures that improvements to the processes reflect change requirements by both internal and external events that will maintain a cohesive enterprise.  So how do we maintain a cohesive enterprise?  We must begin the creation of the enterprise architecture with a vision. As in the construction of a home, it cannot begin without a set of drawings or blueprints.  The vision is the strategy of the enterprise.  The strategy is the “what” goals we desire to achieve of the vision. This provides in documentary form a picture for the entirety of the enterprise to view. The vision also establishes the root of all communications concerning the enterprise functions, effectiveness, and efficiencies.  The Why, What and How of the Vision

The “whys” can have many motivating factors:

· Can we get better

· Management of crisis’s

· Change management

· Alignment of the enterprise

The “what’s” could include:

· Increased customer satisfaction

· Cohesive internal communication

· Reduced products/services to market time

· Increase products/services quality

The “hows” could include:

· Consolidate information solutions

· Streamline capital purchasing processes

· Enhance value chain processes

· Increase market exposure

Theses list are by no means exhaustive in presenting elements of the vision, they are only suggestive in facilitating a starting point in creating the vision. There is no such model of enterprise architecting that fits all enterprises. An analogy of this is the enterprises architecture of a business departs away from the tract home architectures in that there may be four models to choose from to purchase of a tract home.  Business architecture is always a custom design because executive management envisions the design.

The Architectural Vision in Summary A well-defined vision document should be no greater than four pages and should have the input of all top management and key stakeholders of the enterprise. The “why,” “what,” and “how” must be the primary focus and elements of the vision document.  If the purpose (vision) of the enterprise architecture is not clear to the entirety of the organization the support and approval of the vision will slowly dissipate which will place the enterprise back into the array of non-alignment that it began.  

A well-defined document should be no greater than four pages and should have the input of top management and key stakeholders of the enterprise. The “why,” “what,” and “how” must be the primary focus and elements of the document.If the purpose () of the enterprise architecture is not clear to the entirety of the organization the support and approval of the will slowly dissipate which will place the enterprise back into the array of non-alignment that it began.

A well-defined document should be no greater than four pages and should have the input of top management and key stakeholders of the enterprise. The “why,” “what,” and “how” must be the primary focus and elements of the document.If the purpose () of the enterprise architecture is not clear to the entirety of the organization the support and approval of the will slowly dissipate which will place the enterprise back into the array of non-alignment that it began.

A well-defined document should be no greater than four pages and should have the input of top management and key stakeholders of the enterprise. The “why,” “what,” and “how” must be the primary focus and elements of the document.If the purpose () of the enterprise architecture is not clear to the entirety of the organization the support and approval of the will slowly dissipate which will place the enterprise back into the array of non-alignment that it began. 

Contact dotNet Framework Solutions for your EA consultation.

An enterprise architecture blueprint provides defined governance and models that guide the organization. It creates the business processes, and enterprise structures which consist of organizational, information, applications, and the IT infrastructure.

This makes it difficult for an established organization to change. For small to mid size businesses (SMB’s) this is extremely true due to isolation of strategies. These [isolated strategies] increase the complexity of the business model because of uncoordinated operations without means of integrated information to verify and modify the strategic blueprints. This drives up cost for the enterprise significantly, which in most cases leads to failure of the enterprise.

More and more, SMB’s are realizing that an enterprise architecture plan (EAP) is essential for achieving and maintaining an effective business operation.  

The structure of the enterprise architecture blueprint

Our experience has provided that the enterprise vision is the key asset to establishing an architecture plan. The vision is the enterprise and how the enterprise predicts to accomplish that vision. There are three subsequent factors from the vision that must be examined:

·   Product(s)/Service(s). This is the “what” element of the vision
·   Processes. This is the “how” element of the vision
·   Resources. This is the “who” element of the vision

Once we have defined the vision and have established the elements of the three primary factors we would have created a draft of the enterprise architecture. The draft would constitute the blueprint to which we defined the internal elements.

In the following weeks to come we will provide detail information about each aforementioned asset of the EA:

·   Vision

·   Products/Services

·   Processes

·   Resources

Enterprise architecture is a journey not a destination! Contact dotNet Framework Solutions for your EA consultation.

This is a valuable question that all SMB’s should evaluate.

Recently as I was speaking to a group of SMB executives and I was surprised to find none viewed their operations or companies as an enterprise!

I will address the question of “How can “small” small businesses most effectively map their business processes when they are in rapid growth mode?”

Let’s evaluate this question in a top-down fashion. We all know that growth, especially rapid growth is a great problem to have. The hidden factor that we should seek is sustainable growth. Before we can begin to map processes to align them with growth there must be a top-level plan in place to ‘capture’ processes to map.

Most SMB’s seek niche markets to present there goods and services. Most SMB’s top management has various experiences of management. The issue at hand is a great many of them do not have the where for all to take their vision and formulate it into a living plan that becomes tangible. Hence, in reference to the latter part of your question one can have rapid growth by a niche that the markets demands and disorganized processes support that niche which may drive rapid growth. This provides a false being of security because accounting displays great numbers.

How can we throttle back that growth and capture processes to guide that growth? Here are a couple of ideas.

· Capture the vision and strategy

· Implement an Enterprise Architecture plan of the captured vision and strategy

Now we are on the path of architecting the business with a proven Enterprise Architecture (EA) methodology – and yes a SMB is an enterprise – we can allow the governance of the EA plan to consume the operations to which we can encapsulate the processes. Now that we have encapsulated the processes we introduce a BPM methodology that is best suited for the EA plan established.

Let’s review what we have accomplished to this point.

· We have taken the vision and strategy and created a EA plan – the house Blueprint

· This has tamed our rapid [uncontrolled] growth – we’re not pouring the foundation and framing our house simultaneously

· With the EA plan in place we can now organize and drive our processes through our BPM methodology – we call in our plumbers, electrician, mason’s in a manner that controls workflow and the building of our house.

Let’s view our BPM methodology in a slightly more detail view since this is the primary strength of your question.

A good BPM implementation will provide continues feedback to top management to suggest a change is needed in the implementation of BPM solution itself. This is ensured by the ‘future view’ of the EA plan. To take it a step further the BPM should be integrated with a CRM methodology to become closer to a closed-loop business strategy.

The BPM should identify processes that have little value and processes that may present greater value if redefined.

As for a training tool, I would caution the use of BPM as such. I would use the BPM model as a ‘what-is’ view, not as a ‘how-to’ view. The reason being is that the BPM should create the training process itself.

In summary a well-defined EA plan will lead to an organized BPM implementation that will encompass a CRM solution that will drive sustainable growth for a SMB.

Contact dotNet Framework Solutions for your EA consultation

There are a number of reasons why we continuously change our enterprise applications, but sometimes it’s hard to explain to the requester why another change would be so costly and time-consuming to implement. IT leaders who want to be fully prepared for inevitable changes in the corporate software infrastructure should do their best to avoid system coupling on both business and technological levels.

A modern enterprise information system (EIS) consists of hundreds of applications to support business activities in the enterprise. The degree of application coupling or integration identifies the difficulty of making changes to them. Although coupling has been always used to describe the connections between application’s components, it can be also used to describe relations between applications within the entire EIS.

Applications shouldn’t be thought of as a system created forever. In a properly constructed EA plan they can’t be. Technology is always improved, new data is collected, organizations are restructured, merges occur, and new laws and regulations are passed, all of which affect the EIS. High coupling is a trait that complicates systems maintenance and makes it more expensive to manage. Highly coupled solutions are more difficult to modify since changes made in one place cause changes to be made somewhere else. Although coupling is essential to the connected applications that should have common assumptions about their interaction processes, we should typically work towards decreasing these levels of coupling.

The last technological response to the coupling and integration problems is Service-Oriented Architecture (SOA).

There are two major aspects of coupling - technological and functional. They are addressed in different ways by different people.

Technological coupling is the result of assumptions about transport protocols, data encoding schemes, authentication mechanisms, and so on. This aspect is the responsibility of system architects.

Functional coupling comes from assumptions about the process of interaction and exchanged data. This aspect should be addressed by analysts and domain experts.

Technological Coupling