Thursday Aug 13, 2015
Wednesday Mar 04, 2015
By Ted McLaughlan on Mar 04, 2015
There are three primary and distinct roles to consider, whether
you're building or buying DaaS - regardless of the type or
characteristics of data that's being exchanged; big data, open data,
fast data, IoT/IoE data, metadata, microdata, multimedia content,
structured, non-structured, semi-structured...ALL DATA.
The DaaS Consumer - who needs not only to acquire data from
somewhere (in a way that shields them from the underlying technology
concerns), but also then may use it to develop information apps and
services, or repackage the data to share further with others. The
consumer assigns and realizes value from the service.
The DaaS Provider - who actually builds, markets and
operates the business service and categorized storefront (or catalog),
and brokers or stewards the data quality & availability, data
rights, licenses and usage agreements between the consumers and the
original data owners. The provider creates, shapes and deploys the
opportunities for value-enablement of specific data assets.
IT Services Management - who design, implement and operate the information and data management infrastructure the DaaS Provider relies upon - and manage the IT component and services portfolio this infrastructure includes. For example the databases, virtualization technologies, data access services, storage and middleware capabilities. (Note that "IT Services Management" may be a wholly 3rd-party role, as well as a role within the DaaS Consumer or Provider organizations - there may be 3 or more IT Services Management domains).
There's also a less distinct, more broadly relevant role - the DaaS Enabler.
a.k.a. the "Enterprise Architect", which can be a person, a role, or an
organizational capability. The EA scope includes a heavy focus on
enterprise "universal" information management and governance, infused
(particularly in the Public Sector) with the currently vogue
philosophies of SOA, Open Data, Mobility, Privacy-by-Design (PbD)
and Cloud Computing. (Note that DaaS does not have to be delivered via a
"cloud" deployment model - it's equally-applicable delivered as a
private data services virtualization platform, for example).
Friday Jan 23, 2015
By Ted McLaughlan on Jan 23, 2015
The Northern Virginia Technology Council's (NVTC) Digital Strategy Committee (#nvtcdigstrat) recent event regarding Digital Strategy and Public Safety, featuring Richard R. Bowers - Chief, Fairfax Fire Department - revealed several very interesting and useful challenges for the NOVA business community.
Not least of which was the current challenges around focused, resourced digital strategy planning across the County constituent agencies, and among local jurisdictions.
Many targeted capabilities and improvements in "front-end" digital tools, outreach and engagement, plus initiatives on the "back-end" to handle system-specific data and information management are certainly underway, but information-sharing among the public safety stakeholders - businesses, government and the public - remains a strategic planning, governance and education hurdle to address. In other words, a B2G2C digital strategy challenge.[Read More]
Tuesday Sep 02, 2014
By Ted McLaughlan on Sep 02, 2014
Tuesday Mar 25, 2014
By Ted McLaughlan on Mar 25, 2014
Recent government policies and public demand for open data is rapidly exposing both opportunities and challenges within government information-sharing environments, behind the firewall - in turn a fantastic opportunity and challenge for the Enterprise Architects and Data Management organizations.
Friday Oct 25, 2013
By Ted McLaughlan on Oct 25, 2013
Wednesday Jul 24, 2013
By Ted McLaughlan on Jul 24, 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.
- DATA Act IT Infrastructure - Platform Consolidation, Virtualization & Collaborative Governance as Change Enablers
- 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