Showing posts with label Clinger-Cohen Act. Show all posts
Showing posts with label Clinger-Cohen Act. Show all posts

December 17, 2012

As Is--Where's The To Be?

I saw this "As Is" license plate on a car and I was wondering whether he was selling it as is, loved it as is, and perhaps whether on the back was another plate that said "To Be."

Maybe, his "as is" is a Mercedes, but his to be is a BMW or Lexus? 

Or perhaps, his as-is car is black, but his dream to-be is red?

Then again, maybe he is hopelessly in love with his wife and he has the as is car, but his wife has the to be--now I think I am on to something!

Alternatively, I've simply overdosed on enterprise architecture, and I can't help thinking--what's an as is without a to be? 

Like peanut butter without jelly, it just doesn't work--even on a license plate! ;-)

(Source Photo: Andy Blumenthal)

Share/Save/Bookmark

May 31, 2009

From Pigging Out to Piggybanking

Recently there was some media interest in the government system of funding allocation, which essentially rests on one principle: “Use it or lose it.” Unlike in the private sector, where unused funds may be reserved for future use, money that is not spent in a given appropriation year is simply returned, for the most part.

In our own personal financial worlds, in fact, it is a primary lesson that we should not spend every dollar we earn. Rather, any financial adviser will tell you that money must be managed over many years, including saving money for the proverbial “rainy day” (the recent financial meltdown and recovery act not withstanding).

In business as well as in our personal lives, we are taught to do three things with our money:

·      Spend some—for business operating expenses or living expenses in our personal lives.

·      Save some—for unexpected needs like when a economic recession negatively impacts business cash flow or in our personal lives when a job is lost and we need savings to tide us over; or the saving could be for opportunities like to accumulate funds to get into a new business or to save up for a deposit on a home.

·      Invest some—for longer-term needs like research and development, potential business acquisitions, and so forth or in our personal lives for college education, weddings, retirement and more.

My question is why in government is there not an option #2 or #3—to save or invest funds for the future, like we have in our personal lives and in business?  Why can’t agencies and lawmakers plan longer-term and manage funds strategically instead of tactically—beyond the current year here and now?

The Clinger-Cohen Act of 1996 called for the development and maintenance of an IT architecture, since interpreted more broadly as the mandate for enterprise architecture, where we plan and govern investments strategically (i.e. no longer based on short-term gut, intuition, politics, or subjective management whim).

Managing for enterprise architecture necessitates that we manage business and IT investments with the ability to spend, save, or invest as necessitated by agency mission and vision, customer requirements, and the overall investment climate (i.e. the return on spending versus the return on saving or longer-term investment).

Managing money by driving an end of year spend-down seems to negate the basic principles of finance and investing that we are taught from grade school and that we use in business and our personal lives.

By changing the government budget process to allow for spending, saving, and investing, we will open up more choices to our leaders and hold them responsible and accountable for the strategic long-term success of our vital mission.


Share/Save/Bookmark

May 22, 2009

Enterprise Architecture 3.0

In enterprise architecture, we routinely plan for new information technologies and not enterprise anything. In fact, what we now interpret as the federal mandate for “enterprise architecture”, the Clinger-Cohen Act of 1996 really mandated not enterprise, but “IT architecture”. Here, architects didn’t typically develop enterprise (or common) solutions, but rather stovepipe solutions per customer demand. I would call this Enterprise Architecture 1.0.

As enterprise architecture evolved, we saw it mature in its implementation and expand beyond pure technology into the realm of business process reengineering and improvement. This manifested itself in the Federal Segment Architecture Framework of 2008, where we now looked to solve business, not IT, problems for logical business segments of the organizations. This is Enterprise Architecture 2.0.

However, even at this level of maturity, it continued to be somewhat rare to find enterprise architecture that looked at how we are transforming people, organizations, culture, and society itself. This is now beginning to be demonstrated in the architecture using social media and the larger implications of widespread information sharing, collaboration, and broader citizen participation. I would propose that this larger view of, and larger participation in, enterprise architecture is the next evolution and represents Enterprise Architecture 3.0.

Interestingly enough, I read in ComputerWorld, 18 May 2009, an article that took just such a enterprise architecture 3.0 view, called “Are Computers Transforming Humanity” by Mary K. Pratt.

Note, it’s not that these types of articles have not appeared in the past, but rather that they were not as frequent and this thinking not as endemic to the everyday IT planning discussion as it is becoming today.

The article states: “We’ve always had the introduction of new technologies that transform and move society in new ways. It changes our interactions, our sense f the world and each other…what individual and cultural transformations do, new computer technologies portend.”

Here are some of the EA 3.0 trends I gleaned from the article that are starting to manifest in people, organizations and society:

Convenience weighing on privacy—We can plan for new technologies (for example, mobility solutions that yield “quick answers and fast transactions”) to continue that advance of convenience and challenging traditional privacy concerns. As the article states: “what we let hang out there has changed.”

Reaching across all boundaries—new technologies will continue the miraculous feat of breaking down organizational and societal stovepipes. “One of the things that is different today isn’t that we can just act collectively very quickly, but we act across heterogeneous groups.” Plan for IT to reach across boundaries globally (and even inter-galatically, in the not too distant future).

Digital narcissism—technologies are enabling people’s self-indulgent practices where they often use social media tools to “reinforce and further rationalize overblown esteem for their mundane opinions, tastes and lifestyle choices.” We web 2.0 tools like blogs and twitters and social media everyone can have their own soapbox to evangelize from.

Multi-tasking galore—with the constant barrage of new technologies and communications from them, we are forced to multi-task like never before. “Studies have found that the amount of attention many of us can devote to a single specific task is about three minutes—15 minutes at most.”

Learning by doing—“Why should we memorize facts and figures when search engines, databases, and increasingly powerful handheld computing devices make them instantly available?” What we used to have to memorize, we can now just do the look-up for.

The implications of moving and maturing to Enterprise Architecture 3.0 are exciting and will have us thinking long and hard about the implications of what we do in and with information technology well beyond anything we have done before with IT for individuals, units, or line of businesses.

The changes from IT are broader-based than before and we need IT leaders who can plan and govern these larger scopes. Recently, This was evident with the appointment by President Obama of a federal CIO and CTO to oversee the extraordinary shifts in how we can and will use technology going forward in our nation and with our partners globally.


Share/Save/Bookmark

October 26, 2007

CIO and Enterprise Architecture

The Chief Information Officer (CIO) is the executive in charge of information technology in an organization. All information systems design, development, operations & maintenance, datacenter and support operations fall under CIO jurisdiction. Increasingly, CIOs are involved in creating business and e-business opportunities through information technology. Collaborating with other executives, CIOs are often working at the core of business development within the organization. (adapted from PCMAG.COM)

From this definition, we see two important roles for the CIO.

  1. Operations—the CIO is responsible for the IT operations of the organization (systems, datacenter, and so on).
  2. Strategy—the CIO plays a critical role in strategy and architecture (business and e-business opportunities).

In short, we can summarize the role of the CIO as follows:

CIO = Strategy + Operations

While the CIO has traditionally managed IT operations, we can see the CIO’s role and responsibility expanding more and more into strategy and architecture. Here are some other examples of this:

• “Typically, a CIO is involved with analyzing and reworking existing business processes, with identifying and developing the capability to use new tools, with reshaping the enterprise's physical infrastructure and network access, and with identifying and exploiting the enterprise's knowledge resources. Many CIOs head the enterprise's efforts to integrate the Internet and the World Wide Web into both its long-term strategy and its immediate business plans.” (TechTarget.Com)

• “The Chief Information Officer of an executive agency shall be responsible for…developing, maintaining, and facilitating the implementation of a sound and integrated information technology architecture for the executive agency”. (Clinger-Cohen Act).

More and more, we see the CIO focusing on architecture and the overall policy and planning of IT, while the Chief Technology Officer (CTO) handles day-to-day IT operations.

Share/Save/Bookmark

October 13, 2007

NASA and Enterprise Architecture

First all of all let me say that NASA and its people are totally awesome.

On July 20, 1969, the human race accomplished its single greatest technological achievement of all time when a human first set foot on another celestial body.” (NASA)

The trip to from the earth to the moon is approximately 240,000 miles!! (adapted from Wikipedia)

“Neil Armstrong and Edwin Aldrin spent a total of 21 hours on the Moon, two-and-a-half of them outside the landing module. A further 10 astronauts traveled to the Moon in another six missions with the final manned lunar landing, Apollo 17, completed in December 1972.” (adapted from
http://news.bbc.co.uk/)

On 20 September, 2005, NASA Administrator Michael Griffin announced a New Spaceship Designed for Travel to Moon and Mars. Griffin defended the $104 billion dollar lunar program, saying it is intended to make President Bush's Vision for Space Exploration a reality. The price of the new lunar program will be spread out over 13 years and adjusted for inflation represents about 55 percent of what the Apollo space program cost in the 1970s. (adapted from globalsecurity.org)

Question:
Why haven’t we been able to send man back to the moon (or to other planets in the last 35 years)? And why do we need to invest another $104 billion to do something that we should already know how to do? Finally, if we were able to go to the moon before the unbelievable technological advances of the last 35 years, why can’t we do it today?

Honest answer:
I don’t really know.

Hypothetical answers:
  • The alien technology that we acquired to make the trips to the moon has either been depleted or destroyed by the Russians. (Ha ha ha)
  • User-centric EA wasn’t around 35 years ago, and therefore, the business and technical processes, information, and means of governance weren’t well documented and have been lost to mankind, and now we need to recreate the whole darn thing (hopefully not).


Barring another Roswell alien landing, we will have to thank the Clinger-Cohen Act for helping us ensure that this critical (and expensive) information is better documented going forward.


Share/Save/Bookmark

August 12, 2007

Enterprise Architecture: Program or Project?

Enterprise Architecture is a program with many phases and projects.

Several times in my career, I have been brought in to develop an enterprise architecture for an organization, and just about every time, the boss has asked how long will it take, when will it be done, or some other similar version to time-bind the effort.

However, for those of us who are practitioners in the field of EA, we know resolutely the answer is that EA is never done.

Legally, EA is mandated by the Information Technology Management Reform Act (a.k.a. the Clinger-Cohen Act). As such, it is not a one-time event, but an ongoing requirement, and thus an established program in every department of the federal government.

But more than that, EA defines the current, target, and transition plans for an organization. And by definition, a current and target are just snapshots in time, which are in essence outdated a moment after you publish (just like when you drive a new car off the dealer lot and it immediately becomes “used.”) That is, an organization, its business and technology, are constantly evolving and in a state of flux, responding to internal and external factors (such as new mission challenges, business opportunities, congressional or executive mandates, changing customer expectations, new technologies, and so on). So in an ever-evolving organization, the “current” state does not stay current, and the “target” does not stay current (up to date). That is, unless you place these under “maintenance,” i.e. you refresh these on a periodic basis, and make course corrections along the way.

Further, developing and maintaining an EA for any organization is a challenging task, especially for a large and complex organization (like many in the federal government). As such, EA efforts need to be broken down into smaller projects to be successful. And these projects need to be clearly defined in terms of scope, schedule, and performance measures and managed for all project knowledge areas (reference: Project Management Book of Knowledge).

So the next time your boss asks you, “When will the EA be done?” I suggest you tell them: “The EA is a program with many phases and projects. Phase (#) is scheduled to roll out (date).”

Has this ever happened to you – that your boss asked you when the EA would be finished? What did you say/do?


Share/Save/Bookmark

August 9, 2007

What can ITIL teach us about EA

The Information Technology Infrastructure Library (ITIL) and User-Centric Enterprise Architecture are both customer driven and focused on providing users what they need to carry out the mission of the organization. Both are about achieving results.

ITIL and user-centric EA look like they compete, but really are mutually supportive. Here’s how:

  • ITIL is a framework of best practices that seek to provide information technology service support and delivery to the end-user; User-centric EA focuses on the end-user and seeks to provide them useful and usable products and services.
  • ITIL looks to match service levels to user requirements; user-centric EA looks to match technology solutions to business and information requirements.
  • The ITIL framework has both a business perspective and an IT perspective — sounds familiar to EA? EA synthesizes business and technology information for enhancing decision making.
  • ITIL looks at all the following: business, applications, infrastructure, security, service, and planning; EA’s views include business, performance, information, service components, technology, security, and develops the plans for these.
  • ITIL is an outgrowth of the United Kingdom’s Office of Government Commerce; EA is rooted in the United States Clinger-Cohen Act and the Office of Management and Budget’s Federal Enterprise Architecture.
  • ITIL provides goals and activities for all types of IT processes including: the management of configuration, incidents, problems, change, service levels, finance, availability, security, capacity, and continuity; EA provides an as-is, to-be, and transition plan for information systems and technologies in relation to performance, business, and information requirements. Both ITIL and EA are looking to enhance mission execution.

At the end of the day, both ITIL and user-centric EA provide a framework and structure for IT to better service the business and its end-users. ITIL will provide for the process side and EA will do the same for the planning and governance.


Share/Save/Bookmark

July 21, 2007

How To Do It Right - Rule of Thumb #1

From my experience, there are a number of ways to transform your EA into a user-centric model. In this post I will talk about the first one: Have a clear value proposition.

Remember, doing EA because "it's the law" (Clinger-Cohen Act) is not focusing on the users!

One example of a clear value proposition is that "EA will improve our IT planning and governance" (and thereby enable better decision making by the end users).

It was not until I started speaking in these terms that anyone in my agency would give me the time of day.

Share/Save/Bookmark