Friday Oct 25, 2013

Hybrid IT or Cloud Initiative – a Perfect Enterprise Architecture Maturation Opportunity

All too often in the growth and maturation of Enterprise Architecture initiatives, the effort stalls or is delayed due to lack of “applied traction”. By this, I mean the EA activities - whether targeted towards compliance, risk mitigation or value opportunity propositions – may not be attached to measurable, active, visible projects that could advance and prove the value of EA. EA doesn’t work by itself, in a vacuum, without collaborative engagement and a means of proving usefulness. A critical vehicle to this proof is successful orchestration and use of assets and investment resources to meet a high-profile business objective – i.e. a successful project.[Read More]

Tuesday Jul 16, 2013

What is culture and how does it affect the practice of Enterprise Architecture?

As Architects we often spend countless hours working toward delivering great artifacts, including a future state, current state and roadmap to assist our customers in developing a vision and plan toward transformation or maturity. This work is often completed and finds its place on the CIO’s bookshelf or the Lead Architect’s desk with little action or even a second look. Why is this work not actively embraced by many organizations beyond the IT walls or even within the IT organization?

Don’t misunderstand my position, I believe all of the work completed during an iterative EA process that outputs the artifacts I mentioned above add value, although if the organization is not “culturally” ready to embrace the work and transform then the effort is for not.

Culture is defined in many ways by many scholars, although I find it easiest to define culture as interactions and relationships between members of an organization or unit within that organization. This assumes there is an organizational culture and sub cultures within that organization. With this said, it is important that we as architects focus on the overarching organizational culture to better understand whether our customers are ready for an EA engagement.

Our first priority is to ensure we are engaged with the highest level of sponsorship within the organization. For instance, developing physical architectures with the platform division does not constitute Enterprise Architecture, but rather a Technical Architecture and will only have an effect on that sub culture within the organization. EAs need to ensure they are seated alongside the CIO, CFO, COO or even the Chief Executive to ensure efforts toward cultural transformation can be enabled via strong sponsorship.

In the public sector this can be a difficult task as most executives are focused on business related practices and often see the CIO and vendors as “IT focused.” It is critical for our communication during initial contact to be business focused. Conversations about technology are not held until key items, like capability modeling, guiding principles and governance structures are embraced by the organization as a result of cultural change. Once these cultural elements are embraced and socialized technology decisions will be easily facilitated with little debate or power struggles. Remember, the “sponsor” understands how important organizational transformation is at this point in the evolution and will help sub groups understand the vision. Communication and vision are critical elements at this point in the journey toward transformation.

Once we have commitment from the sponsor it is critical for the sponsor to understand the partnership needed between the EA Team and Executive Team. The EA Team is not chartered with creating mission, vision, strategy etc. but rather with understanding the Executive Team’s goals and objectives for the organization and aligning the technology investments with these goals and objectives. Every investment decision made is a direct representation of how the organization’s culture is manifesting itself physically.

Monday Jun 03, 2013

An Integrated Electronic Health Record Needs Enterprise Architecture for Communicating Separation of Concerns

Achieving true progress in creating integrated AND interoperable electronic healthcare management and information systems is very much a real-world, current-day Enterprise Architecture (EA) challenge - and it starts with "separating the business and technical concerns" using standardized EA methods, vocabularies and reusable assets. The manner in which the challenges are communicated, in particular, would benefit all stakeholders and acquisition managers. [Read More]

Monday Apr 08, 2013

Launching an Enterprise Architecture Program within State, Local, Municipal Organizations

When launching a formal EA program, Government organizations often begin by socializing the overall benefits of EA and developing an EA Charter and Plan.  However, while both of these are valuable, they are more useful as part of after-the-fact documentation and communication plans.  Having worked with a broad spectrum of state, local and municipal government organizations across the US and Canada, our team, Oracle's Public Sector Enterprise Strategy Team (EST), has found that the first and primary focus in launching an EA program should be on how to meaningfully engage top business leaders and other stakeholders to discover their needs, identify what would bring the most value to the organization, and obtain their buy-in and support for EA as a key enabler in helping the organization achieve its mission objectives. 

[Read More]

Thursday Mar 14, 2013

An Agile Enterprise Architecture (EA) Delivers Critical Business and Mission Agility

An agile approach to Enterprise Architecture is entirely possible within the formal Oracle Enterprise Architecture Framework - and is essential for business and mission agility within tough and constrained budget contexts.[Read More]

Tuesday Dec 04, 2012

Selling Federal Enterprise Architecture (EA)

Selling the concept and value of an Enterprise Architecture program within the Federal Government requires a marketing and communications strategy that's guided by a reusable taxonomy of subjects to be addressed.[Read More]

Wednesday Sep 05, 2012

Create a Social Community of Trust Along With Your Federal Digital Services Governance

The Digital Services Governance Recommendations were recently released, supporting the US Federal Government's Digital Government Strategy Milestone Action #4.2 to establish agency-wide governance structures for developing and delivering digital services.

Graphic showing the layers of digital services (information, platform, and presentation) built on a platform of security and privacy and delivering to final customers.

Figure 1 - From: "Digital Services Governance Recommendations"

While extremely important from a policy and procedure perspective within an Agency's information management and communications enterprise, these recommendations only very lightly reference perhaps the most important success enabler - the "Trusted Community" required for ultimate usefulness of the services delivered. By "ultimate usefulness", I mean the collection of public, transparent properties around government information and digital services that include social trust and validation, social reach, expert respect, and comparative, standard measures of relative value. In other words, do the digital services meet expectations of the public, social media ecosystem (people AND machines)?

A rigid governance framework, controlling by rules, policies and roles the creation and dissemination of digital services may meet the expectations of direct end-users and most stakeholders - including the agency information stewards and security officers. All others who may share comments about the services, write about them, swap or review extracts, repackage, visualize or otherwise repurpose the output for use in entirely unanticipated, social ways - these "stakeholders" will not be governed, but may observe guidance generated by a "Trusted Community". As recognized members of the trusted community, these stakeholders may ultimately define the right scope and detail of governance that all other users might observe, promoting and refining the usefulness of the government product as the social ecosystem expects.

So, as part of an agency-centric governance framework, it's advised that a flexible governance model be created for stewarding a "Community of Trust" around the digital services. The first steps follow the approach outlined in the Recommendations:

Step 1: Gather a Core Team

In addition to the roles and responsibilities described, perhaps a set of characteristics and responsibilities can be developed for the "Trusted Community Steward/Advocate" - i.e. a person or team who (a) are entirely cognizant of and respected within the external social media communities, and (b) are trusted both within the agency and outside as practical, responsible, non-partisan communicators of useful information. The may seem like a standard Agency PR/Outreach team role - but often an agency or stakeholder subject matter expert with a public, active social persona works even better.

Step 2: Assess What You Have

In addition to existing, agency or stakeholder decision-making bodies and assets, it's important to take a PR/Marketing view of the social ecosystem. How visible are the services across the social channels utilized by current or desired constituents of your agency? What's the online reputation of your agency and perhaps the service(s)? Is Search Engine Optimization (SEO) a facet of external communications/publishing lifecycles? Who are the public champions, instigators, value-adders for the digital services, or perhaps just influential "communicators" (i.e. with no stake in the game)? You're essentially assessing your market and social presence, and identifying the actors (including your own agency employees) in the existing community of trust.

Step 3: Determine What You Want

The evolving Community of Trust will most readily absorb, support and provide feedback regarding "Core Principles" (Element B of the "six essential elements of a digital services governance structure") shared by your Agency, and obviously play a large, though probably very unstructured part in Element D "Stakeholder Input and Participation". Plan for this, and seek input from the social media community with respect to performance metrics - these should be geared around the outcome and growth of the trusted communities actions. How big and active is this community? What's the influential reach of this community with respect to particular messaging or campaigns generated by the Agency? What's the referral rate TO your digital services, FROM channels owned or operated by members of this community? (this requires governance with respect to content generation inclusive of "markers" or "tags").

At this point, while your Agency proceeds with steps 4 ("Build/Validate the Governance Structure") and 5 ("Share, Review, Upgrade"), the Community of Trust might as well just get going, and start adding value and usefulness to the existing conversations, existing data services - loosely though directionally-stewarded by your trusted advocate(s).

Why is this an "Enterprise Architecture" topic? Because it's increasingly apparent that a Public Service "Enterprise" is not wholly contained within Agency facilities, firewalls and job titles - it's also manifested in actual, perceived or representative forms outside the walls, on the social Internet. An Agency's EA model and resulting investments both facilitate and are impacted by the "Social Enterprise". At Oracle, we're very active both within our Enterprise and outside, helping foster social architectures that enable truly useful public services, digital or otherwise.

Monday Aug 06, 2012

Sequestration Planning May Illuminate Value Engineering via Enterprise Architecture

 The next 5 months portend a spectacle of US Congressional battles to be waged ahead of the pending, mandatory “sequester” - automatic, mandatory federal government spending reductions of about $1 Trillion over 9 years, in non-exempt, discretionary appropriations, set to take effect 1/2/2013. Forward-thinking planners in government IT organizations, in large Programs that depend upon IT, and among the Systems Integration (SI) community are likely to dust off Enterprise Architecture skills for analyzing budget cut implications across their IT investment portfolios, and possible cost savings opportunities to offset them. Leveraging a methodical, EA-guided approach to both assess impacts and adjust spending priorities, while illuminating new areas of savings, is a sure route to mitigating serious risks and delays to delivery of critical citizen services.

Whether you’re dusting off the existing EA artifacts, or need to take a very rapid, optimized route to constructing initial enterprise IT models, the driving principle at this time will be rapid, absolute reduction in complexity with a clear line-of-sight to cost savings. “Complexity” here simply refers to an inefficient or needlessly detailed volume of time and resources applied to deliver IT solutions – time spent re-engineering processes, building redundant interfaces and monitors, installing hardware & software in a piecemeal fashion.

Driving complexity, and therefore introducing cost savings, out of engineered systems is the central tenet of “Value Engineering”  – “the optimization of a system’s outputs by crafting a mix of performance (function) and costs”. Essentially, deliver the same capabilities with better value by driving down the cost to build and/or operate. Section 52.248-1 of the FAR (Federal Acquisition Regulations) describes the “Value Engineering Clause” that is inserted into many large Federal IT contracts – enabling the contractor to propose changes to the system being developed (i.e. a “Value Engineering Change Proposal”, or VECP). If the proposal is accepted, the actual or collateral savings derived by the government (through cost modification to the contract) can be shared with the contractor. It’s a win-win opportunity for the government, system beneficiaries and the contractor community to discover and propose engineering changes that will lower costs, yet still deliver the same or better results.

Many VECPs are submitted for technology assets – i.e. contained systems that may work better when newer, less-costly components are substituted…like missile systems or electronic devices. This may be because the contractor typically is the sole source of knowledge and research concerning how to optimize and build the components, the “value” and function of the asset is very clear (i.e. it’s delivered and explodes on target) and constant innovation is a demand of the environment. VECPs are also submitted for IT systems and programs, though it’s much more difficult to identify and propose the specific cost savings or cost avoidance that might result – since IT systems are frequently dependent upon many external or interfaced elements, vendor products and processes.

An EA-centric review of a program or line-of-business IT investment may quickly yield insight that would lead to specific value engineering opportunities, and therefore reductions in IT costs. For example, a particular set of information may be created, shared and recreated across several systems, using different processes, datastores and technologies. An segmented EA approach driving down from the particular business, process and information domains, may quickly illuminate targets of opportunity for database or interface consolidation – and therefore potential consolidation of supporting technologies (i.e. storage, networking, processors). This may lead to optimized technical operations and business process performance, which can be clearly mapped back to the Enterprise Architecture to validate that governance and mission requirements are (still) met, cross-enterprise risks are mitigated, and IT investment portfolios and procurement activities are properly adjusted or re-aligned.

With this kind of information, a VECP could be constructed that very clearly proposes both program-specific and collateral (i.e. across the rest of the enterprise) savings resulting from introduction of state-of-the-art consolidating technologies (for example, pre-integrated, self-contained and consolidated database engineered systems, perhaps cloud-enabled). At the very least, an EA view can help identify and prioritize targets of opportunity for Value Engineering that may become part of an effective and timely sequestration response – both before and after such an event, and in fact as part of the annual capital planning and investment control (CPIC) processes.

Monday Jul 02, 2012

An Actionable Common Approach to Federal Enterprise Architecture

The recent “Common Approach to Federal Enterprise Architecture” (US Executive Office of the President, May 2 2012) is extremely timely and well-organized guidance for the Federal IT investment and deployment community, as useful for Federal Departments and Agencies as it is for their stakeholders and integration partners. The guidance not only helps IT Program Planners and Managers, but also informs and prepares constituents who may be the beneficiaries or otherwise impacted by the investment. The FEA Common Approach extends from and builds on the rapidly-maturing Federal Enterprise Architecture Framework (FEAF) and its associated artifacts and standards, already included to a large degree in the annual Federal Portfolio and Investment Management processes – for example the OMB’s Exhibit 300 (i.e. Business Case justification for IT investments).

A very interesting element of this Approach includes the very necessary guidance for actually using an Enterprise Architecture (EA) and/or its collateral – good guidance for any organization charged with maintaining a broad portfolio of IT investments. The associated FEA Reference Models (i.e. the BRM, DRM, TRM, etc.) are very helpful frameworks for organizing, understanding, communicating and standardizing across agencies with respect to vocabularies, architecture patterns and technology standards. Determining when, how and to what level of detail to include these reference models in the typically long-running Federal IT acquisition cycles wasn’t always clear, however, particularly during the first interactions of a Program’s technical and functional leadership with the Mission owners and investment planners. This typically occurs as an agency begins the process of describing its strategy and business case for allocation of new Federal funding, reacting to things like new legislation or policy, real or anticipated mission challenges, or straightforward ROI opportunities (for example the introduction of new technologies that deliver significant cost-savings).

The early artifacts (i.e. Resource Allocation Plans, Acquisition Plans, Exhibit 300’s or other Business Case materials, etc.) of the intersection between Mission owners, IT and Program Managers are far easier to understand and discuss, when the overlay of an evolved, actionable Enterprise Architecture (such as the FEA) is applied.  “Actionable” is the key word – too many Public Service entity EA’s (including the FEA) have for too long been used simply as a very highly-abstracted standards reference, duly maintained and nominally-enforced by an Enterprise or System Architect’s office.

Refreshing elements of this recent FEA Common Approach include one of the first Federally-documented acknowledgements of the “Solution Architect” (the “Problem-Solving” role). This role collaborates with the Enterprise, System and Business Architecture communities primarily on completing actual “EA Roadmap” documents. These are roadmaps grounded in real cost, technical and functional details that are fully aligned with both contextual expectations (for example the new “Digital Government Strategy” and its required roadmap deliverables - and the rapidly increasing complexities of today’s more portable and transparent IT solutions.  We also expect some very critical synergies to develop in early IT investment cycles between this new breed of “Federal Enterprise Solution Architect” and the first waves of the newly-formal “Federal IT Program Manager” roles operating under more standardized “critical competency” expectations (including EA), likely already to be seriously influencing the quality annual CPIC (Capital Planning and Investment Control) processes. 

Our Oracle Enterprise Strategy Team (EST) and associated Oracle Enterprise Architecture (OEA) practices are already engaged in promoting and leveraging the visibility of Enterprise Architecture as a key contributor to early IT investment validation, and we look forward in particular to seeing the real, citizen-centric benefits of this FEA Common Approach in particular surface across the entire Public Service CPIC domain - Federal, State, Local, Tribal and otherwise. Read more Enterprise Architecture blog posts for additional EA insight!

About

Public Sector Enterprise Strategy Team
This blog is written and maintained by the Oracle Public Sector Enterprise Strategy Team. We are a team of senior Enterprise Architects across Canada and the United States dedicated to helping public sector customers use the discipline of enterprise architecture to turn strategy into successful execution.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today