Tuesday Sep 02, 2014
Friday Oct 25, 2013
By Ted McLaughlan on Oct 25, 2013
Tuesday Jul 16, 2013
By zbishop-Oracle on Jul 16, 2013
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
By Ted McLaughlan on Jun 03, 2013
Monday Apr 08, 2013
By user737836 on Apr 08, 2013
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
By Ted McLaughlan on Mar 14, 2013
Tuesday Dec 04, 2012
By Ted McLaughlan on Dec 04, 2012
Wednesday Sep 05, 2012
Monday Aug 06, 2012
By Ted McLaughlan on Aug 06, 2012
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
By Ted McLaughlan on Jul 02, 2012
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!
This blog is written and maintained by the Oracle Public Sector Enterprise Architecture & Strategy Community. We are 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.
- All Data as a Service (DaaS/BDaaS) - Who's Your D-a-a-S Enabler?
- Public Sector Digital Strategy Meets Public Safety - in Northern Virginia, Fairfax County
- US Regional, Metropolitan Area Public Sector "Open Data" Synergies, Opportunities, Challenges
- Public Sector Open Data via Information Sharing and Enterprise Architecture
- Hybrid IT or Cloud Initiative – a Perfect Enterprise Architecture Maturation Opportunity
- The Chief Marketing Technology Officer - CMTO - and the EA
- What is culture and how does it affect the practice of Enterprise Architecture?
- An Integrated Electronic Health Record Needs Enterprise Architecture for Communicating Separation of Concerns
- Launching an Enterprise Architecture Program within State, Local, Municipal Organizations
- An Agile Enterprise Architecture (EA) Delivers Critical Business and Mission Agility