On demand approach to uml

i-Lighted Content On demand approach to uml

Interesting moves in cloud computing

The U.S. Federal Government Defines Cloud Computing
— I’ve just spend the last two days in Washington DC in conversations with various US government officials regarding the opportunities for cloud computing within the federal government. During these conversations it has become very clear that the topic of “Cloud Computing” is front and center within the various departmental IT strategies going forward. All the more interesting is that the term is being mandated from the highest levels including the new federal CIO Vivek Kundra who indicated cloud computing was one of the biggest revolutions technology has seen in a long time.

Kundra’s first 100 day priorities

Open RFPs – increasing citizen value

As a Federal contractor one of the biggest issues we face is access to request for proposals and valid opportunities.  In the past this has been dependent upon relationships and subscriptions to services such as Input.  A new web 2.0 service called the RFP database promises to create transparency and openeness during the procurement process.  check it out.

http://www.rfpdb.com/

How do we determine citizen value if we can’t track the dollars?

http://industry.bnet.com/government/10001419/implementing-the-stimulus-bill-turns-out-to-be-difficult/

adding value for citizens

Restarting the blog

Going to restart the blog and really focus on a couple of areas.  First area to focus on is social networking particularly in the context of enterprise architecture, improving business processes, and making information technology investment decisions.  The second area is use of social networking to help us as taxpayers keep our political leadership accountable and see if the money we are spending is put to good use.

Operational Architecture

A key element to any enterprise architecture is the adoption of an operational based reference model. Many enterprise architectures utilize business, service, data, performance, and technical reference models to construct their enterprise architecture. These reference models provide the context by which to describe the various elements of the enterprise in a common way. While these reference models provide a good construct they are often not specific enough and do not provide users with a true enterprise operational picture. In our experience we have found that users do not receive an operational picture because the architecture tends to be esoteric and represents conceptual business functions, services, data, technologies, and performance measures. While an esoteric architecture can help to understand the enterprise’s big picture it does not help decision makers to make specific tactical decisions about how and what to change within the architecture. To facilitate decision maker’s ability to make tactical decisions we recommend developing an operational overlay for any enterprise architecture. The operational overlay establishes a set of criteria by which elements of the architecture can be described in a clear operational perspective. To create the operational perspective requires the architect to specifically describe the inputs, outputs, and results of each element of the architecture. We have found that clearly articulating these specifics in context of each element of the architecture enables decision makers to not only see the enterprise view but to understand how it is used.

Enterprise Architecture Associations

Associations or relationships identified between the architectural layers and levels of the EA are the key to understanding redundancies or inadequacies within an organization and assist in understanding ways to unify the business functions and information technology resources. We incorporate an analytical approach to compare, evaluate, and analyze the relationships between all layers of an EA including:

-        FEA reference models 

-      Stakeholders

-   Mission, Vision, goals

-     Business architecture metadata

-     Data Architecture metadata        

-       Application Architecture Metadata

-    Technology Architecture Metadata  

The analysis presents a high-level, concise picture of what the metadata in the architecture represents. The high-level representation is ideal for senior level executives who need to make funding decisions or modernize the enterprise. For example, the following scenario demonstrates systems with a high-maintenance cost and a low number of users may need to be retired. Additional analysis may indicate the system may be obsolete and may need to be retired. As a result, our EA Approach can be used to determine:

-      Duplication of effort

-     Disparate and redundant processes 

-     Systems that impede information sharing among programs (ultimately resulting in untimely or inadequate service)

-     Redundant IT support 

-    Overlap in other support functions

-    If the business case for each IT investment demonstrates the relationship between the investment and the business, data, application, and technology dimensions of the EA.

How to use enterprise architecture

Our last entry focused on how we define enterprise architecture and our approach to governance. This week we are going to start a series on the application of enterprise architecture. Applying or using an enterprise architecture is often the step that business people and architects never get to. Often time an architecture project becomes so engrained in the development of the architecture that they lose sight of the forest through the trees. Our first discussion (today’s blog) will describe our approach for developing problem-based enterprise architectures. Upcoming issues of the blog will discuss how enterprise architecture should be utilized to support strategic planning and portfolio management

Figure 1 from Chris Barlow’s three stepping stones is probably the best representation of our view towards enterprise architecture and how it can play a critical role in transforming organizations.

We have found that enterprise architecture delivers the greatest value when it is used as a tool to facilitate the merger of business and information technology by solving real business problems. Too often enterprise architecture is a documentation effort that is not focused on the needs and issues of the business line it is intended to support. Without a business line there is no need for information technology, let alone enterprise architecture.

Solving real business problems should be the goal of any enterprise architecture project. We have seen positive results from taking the time up-front in an enterprise architecture engagement to conduct an outreach effort with key stakeholders, leadership, employees, and customers of the organization. This outreach is intended to be bidirectional. We are making stakeholders aware of the enterprise architecture initiative and its associated outcomes. Stakeholders respond to our directed questions to help identify their issues and needs. This information should be well documented so that it can be referenced when prioritizing the issues and needs. The prioritization is critical to the success of an enterprise architecture project and is a differentiator between our approach and a typical approach to enterprise architecture. Rather than wandering down the path of dividing up areas to be modeled amongst the team and sending them on their way, we focus on the highest priority issues and needs and develop enterprise architecture products to address them. This is an iterative approach with the intention of revisiting products developed as additional issues and needs are addressed. While this may be perceived as some degree of potential re-work; the buy-in gained from focusing on key issues and needs is well worth it. As the issues and needs are addressed the merger between business and information technology begins to take shape and stakeholders begin to see the value of enterprise architecture and look to it as critical tool to solve real problems rather than something that have to do to meet mandated requirements. In our next entry in this series we will focus on how to identify issues/needs and how to engage the right stakeholder support.