Monday Jan 04, 2016

Solving the Polyglot Persistence Puzzle

Solving the Polyglot Persistence Puzzle
- Using the Oracle Information Characteristics Architecture Method

Polyglot – Knowing or using several languages.
Persistence – A coding technique or technology used to store information.
Polyglot Persistence – Storing information in multiple information management technologies to meet a business requirement.

The Polyglot Persistence Puzzle – Combining multiple information management technologies into comprehensive information architectures to meet business requirements.

Today an information architect has a wide array of information management technologies available to solve business problems.  451 Research published a Data Platform Map in June 2015 that identified 277 information management products in 18 categories.  

451reseachdatamap

Three forces have contributed the explosion of information management technologies: 

1. The enormous amount and types of information generated on the internet and by connected devices,
2. The reduction in the cost of compute and storage platforms per a unit of processing capability and,
3. The explosion of open source products for specific information management use cases.

Together, these forces have provided the opportunity for information architects to collect data onto low-cost platforms that only a few years ago would have been deemed too high-volume, too low-value and too expensive to capture.  Hence we are now in the era of Big Data – high-volume, low-value data that can be cost effectively researched, explored and mined.  But experience has shown that the value of Big Data is multiplied many times over of it can be combined with high-value information in existing systems to enhance the quality of decisions made throughout the organization, i.e. solving the Polyglot Persistence Puzzle. This daunting task falls to the Information Architects.  It is the Information Architects that must lead the era of Big Data into the era of Polyglot Persistence for organizations to take full advantage new types of information and information management technologies.

But with this new era comes the need for new ways and methodologies to solve the inevitable Polyglot Persistence Puzzle.

In this series of blog articles, we will introduce and explain such a new methodology – Oracle Information Characteristics Architecture Method (ICAM).  ICAM measures 16 information characteristics and 8 usage patterns to evaluate and value information to assist Information Architects in making the best information management technologies decisions, i.e. the right tools for the right job.  ICAM has been developed with input from many Oracle information management thought leaders from around the world.  We have also worked with a handful of beta customers to implement and refine ICAM with very positive feedback and results.  My colleague, Bill Wimsatt, and I will post several blog articles explaining and walking through the process of implementing ICAM and showing the value of using this methodology.

The next ICAM blog article ‘Why solving the Polyglot Persistence Puzzle is so important today – The Information Value Lifecycle’.

Bill Wimsatt is a Senior Business Technology Professional with a broad background combining business and IT strategy, execution, and program management.  He has over 25 years experience in business and IT strategy and business optimization.

Ron Mayfield is the Senior Enterprise Architect specializing in database and information architectures at Oracle.  Ron has been a professional in the IT industry for 30 years and an employee of Oracle for the last 26 years.

Bill and Ron will be presenting ICAM at the Open Group Towards Boundaryless Information Flow™ in San Fransisco on Wednesday, January 27, 2016, at 9:00 - 9:45pm.  Their presentation is titled ‘Developing Information Architectures via Business Capabilities and Information Characteristics’.

‘Boundaryless Information Flow’ is a trademark of The Open Group.

Monday Sep 21, 2015

Your Next Business Transformations will require a Hybrid Cloud Architecture

This posting represents highlights of the upcoming presentations at the annual Oracle ECA Summit, October 27 at Oracle OpenWorld.  Talk to your Oracle account manager for an invitation - Today!

The public cloud has typically been outside of the domain of enterprise architects. On the surface, it has been considered an external silo where procurement decisions have been driven by line of business executives. But not anymore. Business processes extend into the cloud. And, the cloud extends into the enterprise.

However, this state of affairs is changing rapidly as customers increasingly embrace cloud computing. Enterprise architects are called on not only to review public cloud implementations but also to understand how best to integrate new cloud offerings with existing on-premises information systems. Most companies will have a combination of assets combining public cloud SaaS, PaaS and IaaS with their existing on-premises systems. The marketing folks are calling this Hybrid IT. Enterprise architects therefore face a new set of challenges as they figure out how to integrate these systems with each other.

Today's enterprise architects face a shifting set of circumstances. In the next two years, a growing number of companies plan to move key parts of their computing workloads to public clouds to take advantage of lights-out automated software provisioning and management, rapid project implementation, elastic scalability, and subscription-based pricing models. To keep up with consumer demand, IT has become an external service broker. In some cases IT pros have been forced to support heterogeneous cloud "silos" that may have proprietary methods of security, integration, management, and governance. These trends are forcing core IT departments to formalize enterprise governance and enterprise architecture to mitigate risk.

Oracle ECA Summit Agenda 

The Oracle Enterprise Architecture team has helped a number of large-scale early adopters on their journey to a variety of Hybrid implementations. At this year’s Oracle Enterprise Cloud Architecture Summit, held at Oracle Open World on October 27, 2015, three customer architects will speak to their experiences in building these next generation platforms. See the full agenda and abstracts here.

  • Dev/Test in the Oracle Public Cloud
  • Big Data in the Oracle Public Cloud
  • Integration in the Oracle Public Cloud
As a bonus, Peter Magnusson, SVP Cloud Development, Oracle will clarify the requirements and plans for Oracle’s enterprise-class and production workload cloud services.  Last year, Thomas Kurian, President, Development, Oracle also spoke to the landscape of technology cloud services. You can read that article here.

To learn more about Hybrid IT and Oracle’s Cloud Services, come to Oracle’s ECA Summit, October 27 at Oracle OpenWorld in SF. Talk to your Oracle account manager for an invitation - Today!

Wednesday Mar 20, 2013

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

While working with a recent partner, the question came up; "What changes are made to the EA approach if agile methods are required, or otherwise heavily encouraged?" The initial answer at the time was "Not many – we already have an agile approach to EA embedded in our Oracle Enterprise Architecture Development Process (OADP), and our Oracle Enterprise Architecture Framework (OEAF) is independent of project management and project development approaches."

Our OADP has always been agile and therefore supportive of business and government agility – particularly in the current context of severely constrained budgeting cycles. We firmly believe in a "just enough, just in time" philosophy, with collaborative insight and contribution across teams and leadership, and delivery of EA artifacts or guidance tuned directly to prioritized results. This means strategic, useful and reusable guidance modeled and delivered in a manner that supports both longer-term initiatives and near-term objectives.

EA delivered as an agile approach, however, does require continual line-of-sight traceability back to the IT investment strategy – which in turn is aligned to the business strategy.  

In other words, a Sprint Iteration approach might be justified (i.e. using the "Scrum" strategy), from all relevant perspectives, to quickly establish a reusable process and metadata model for a common agency function – like "Document Routing and Approval" (DRA). The output might be required to inform a software solicitation (i.e. to explain the requirements).  The output might be to establish a reference model and basic governance (business rules) for identifying and improving process efficiencies around the agency where DRA is occurring.

The actual need for this EA artifact (or "Product", in Agile terms) may be driven from an unanticipated mandate or regulatory change, and therefore require rapid response.  The need may also be limited in scope to only a portion of the agency's business (i.e. those who actually know they need it).

So, an EA Sprint will work, and deliver what's needed quickly and effectively to the target audience.  The highest return on investment (ROI) in this exercise, however, only exists if actual Enterprise traceability and impact assessment occurs. In other words, an agile EA output with a strategic Enterprise outcome.

Note this is a common misunderstanding for Agile software development; Agile programming and project management may deliver useful, rapid and cost-effective "features" from a Backlog of priorities, but much of the supporting infrastructure, integrations and organizational change isn't delivered using Agile methods, but must evolve in a more strategic, methodic manner.  Preferably with EA guidance.

Here's what should happen.  The common DRA process, metamodel and business rules begin to shape, in a somewhat parochial "requirements-driven" context, heavily leveraging the impacted SMEs for a short period of time. As this occurs, the Enterprise Architect and stakeholders begin mapping and comparing the DRA process design (at appropriately coarse levels of abstraction) to any similar that may exist within the agency, or among agency partners or stakeholders.  This may require some additional outreach and communication.  The EA may find additional SMEs, risk factors, standards, COTS DRA solution accelerators, overlapping data management projects, etc. – essentially other activities or resources that can be used or might be impacted.

The Enterprise Architect is the Scrum Master!

Strategic oversight and influence is therefore brought to bear on the EA sprint, and by leveraging EA methods, the impacts to the rest of the organization plus any modifications to the focus EA artifact can be addressed – entirely within standard and expected IT Governance. The EA artifact development is a Sprint, but actually leverages our lifecycle methodology – from Business Context through Current and Future States, and then Roadmap (i.e. Transitional Architecture) and Governance.  The EA Sprint may actually kick off or modify a more holistic EA maintenance process.

We are therefore avoiding an "agile everything" philosophy, though we're delivering agile results.   We contribute over-arching guidance and process for both the DRA project and the organization as a whole, to make sure that all projects underway are still aligned to meet the needs of the business and IT investment constraints.

This is essentially what we believe in applying our EA process, over time or during more Agile response cycles; always raise and maintain focus on the business strategy and drivers to guide the investment of IT budget into those areas that affect the business most – or that are the most immediate priority, such as described above.

Thanks to Oracle Public Sector Enterprise Architect Ted McLaughlan for contributing to this article!


Monday Sep 10, 2012

Current State EA: Focus on the Integration!!!

[Read More]

Wednesday May 30, 2012

Who should ‘own’ the Enterprise Architecture?

I recently had a discussion around who should own an organization’s Enterprise Architecture. It was spawned by an article titled “Busting CIO Myths” in CIO magazine1 where the author interviewed Jeanne Ross, director of MIT's Center for Information Systems Research and co-author of books on enterprise architecture, governance and IT value.

In the article Jeanne states that companies need to acknowledge that "architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO". "If the CEO doesn't accept that role, there really can be no architecture."

The first question that came up when talking about ownership was whether you are talking about a person, role, or organization (there are pros and cons to each, but in general, I like to assign accountability to as few people as possible). After much thought and discussion, I came to the conclusion that we were answering the wrong question. Instead of talking about ownership we were talking about responsibility and accountability, and the answer varies depending on the particular role of the organization’s Enterprise Architecture and the activities of the enterprise architect(s).

Instead of looking at just who owns the architecture, think about what the person/role/organization should do. This is one possible scenario (thanks to Bob Covington):
  • The CEO should own the Enterprise Strategy which guides the business architecture.
  • The Business units should own the business processes and information which guide the business, application and information architectures.
  • The CIO should own the technology, IT Governance and the management of the application and information architectures/implementations.
  • The EA Governance Team owns the EA process.  If EA is done well, the governance team consists of both IT and the business.

While there are many more roles and responsibilities than listed here, it starts to provide a clearer understanding of ‘ownership’. Now back to Jeanne’s statement that the CEO should own the architecture. If you agree with the statement about what the architecture is (and I do agree), then ultimately the CEO does need to own it.

However, what we ended up with was not really ownership, but more statements around roles and responsibilities tied to aspects of the enterprise architecture. You can debate the semantics of ownership vs. responsibility and accountability, but in the end the important thing is to come to a clearer understanding that is easily communicated (and hopefully measured) around the question “Who owns the Enterprise Architecture”.

The next logical step . . . create a RACI matrix that details the findings . . . but that is a step that each organization needs to do on their own as it will vary based on current EA maturity, company culture, and a variety of other factors.

Who ‘owns’ the Enterprise Architecture in your organization?

1 CIO Magazine Article (Busting CIO Myths): http://www.cio.com/article/704943/Busting_CIO_Myths

About

Art, Artifacts, and Best Practices for Enterprise Architects

Search

Archives
« July 2016
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
31
      
Today