X

The Enterprise Architecture Blog covers commentary and insights about Cloud and Enterprise Architecture

Recent Posts

AppDev and Integration Major Announcements

I am writing this blog to quickly highlight several announcements that Oracle just made (and it's not even Open World)! Oracle just put this press release out on the next Autonomous Cloud services: Oracle Autonomous Integration Cloud Autonomous Visual Builder Cloud Further, the ability to use Oracle's Platform for modern Cloud Native application development has takes another big leap forward with these announcements: Announcing General Availability version of the WebLogic Server Kubernetes Operator  -The Operator, first released in February as a Technology Preview version, simplifies the creation and management of WebLogic Server 12.2.1.3 domains on Kubernetes.  The GA operator supports additional WebLogic features, and is certified and supported for use in development and production.  OKE is GA - (docs) - Oracle Cloud Infrastructure Container Engine for Kubernetes is a fully-managed, scalable, and highly available service that you can use to deploy your containerized applications to the cloud. Use Container Engine for Kubernetes (sometimes abbreviated to just OKE) when your development team wants to reliably build, deploy, and manage cloud-native applications. OCIR is GA - (docs) - Oracle Cloud Infrastructure Registry is an Oracle-managed registry that enables you to simplify your development to production workflow. Oracle Cloud Infrastructure Registry makes it easy for you as a developer to store, share, and manage development artifacts like Docker images.   Exciting times. The prediction I made about the importance of factoring Artificial Intelligence/Machine-learning into your Enterprise Architecture are becoming more and more true. Luckily, Oracle is helping to make AI/ML a practical reality as it imbues its Cloud Services with intelligence that make them even more impactful to your company or agency's mission.  

I am writing this blog to quickly highlight several announcements that Oracle just made (and it's not even Open World)! Oracle just put this press release out on the next Autonomous Cloud services: Orac...

Enterprise Artificial Intelligence Architecture

Enterprise Artificial Intelligence Architecture If you think back to Greek mythology, an Oracle was a person who provides wise counsel, prophetic predictions, or precognition of the future (as summarized from Wikipedia). So, it is somehow fitting that Oracle, the company, is the first to drive Artificial Intelligence (AI) and Machine Learning (ML) so broadly and deeply into our services. This push allows you to become your own oracle to drive insights, predictions, and customer/employee/partner interactions in ways that will pull you ahead of your competition. AI/ML are game-changing technologies (and have finally come of age) that you need to plan and leverage your Enterprise Architecture for customer and competitive value. If you thought the tsunami of change brought by Cloud Computing was big, get ready. The move to Cloud Computing was merely an enabling step to AI which will come just as fast and be just as consequential to business, if not more so in the long run. The reason this is happening now is the culmination of Oracle's generally available GPUs for AI-compute power, massive data storage/retrieval, and access to core AI/ML capabilities. The move to Cloud allowed your company to divest itself of owning/running infrastructure, platforms, and software. AI/ML will allow you to automate manual, slow, and error-prone activities so that you can focus on creativity and business excellence. Generally, AI should be positioned in your Enterprise Architecture to: Automate as much as possible with the understanding that there is a point where human creativity and interaction can't be replaced. Provide better and faster analytics and decision making. Provide vastly better user, customer, employee, and partner experience/interaction. Develop and deploy applications/services faster and more reliably than ever before. Leverage for new, creative, differentiating services that could never exist before. In terms of architecture, you should look not only at the cost of implementing AI, but the business risk of *not* implementing this technology. You should also think in advance, asking yourself how your Enterprise Architecture can accommodate the following questions: How can you use AI to offer differentiated services more quickly? How can you build applications that offer deeper insights and more personal experiences? What can I do with Autonomous Computing in my company that was impossible before, that your competition would fear now, or our customers will be delighted by?  Mark Hurd just recently predicted that 90% of enterprise apps will have integrated AI by 2020. See the ZDNet article here. Luckily, Oracle recently made a series of announcements about how deeply and broadly AI will be imbued in our Cloud Services which will immediately answer some of the questions listed above. Of course, people who have been to Open World, or generally keeping an eye on things, will remember that we announced the world's first self-driving or Autonomous database (read press release here) to drive up productivity, lower risk, and speed up decision making. Another article goes on to explain how Oracle will provide Autonomous services across the entire platform (read here). The key message is that Oracle is extending Autonomous capabilities by making all our Cloud Platform Services self-driving, self-securing, and self-repairing. This will enable organizations to lower costs, reduce risk, accelerate innovation, and get better predictive insights.  Finally, this Forbes article, "Oracle Extends Autonomous Capabilities Across Its Entire Cloud Platform," does a good job of explaining why AI is suddenly so important and what has changed to make it viable right now as an enabler in business systems. In closing, it’s a very safe bet to focus some of your attention on how to leverage AI/Autonomous computing right now. Do so before your competition because the first one to do it will be the first one to reap the rewards of reduced cost and risk while enjoying the benefits of speed, insight, and differentiation. How to get going? Start by asking the key questions mentioned above. When your Enterprise Architecture and supporting team have the answers then your company will be better able to rise with the Autonomous tsunami happening right now.

Enterprise Artificial Intelligence Architecture If you think back to Greek mythology, an Oracle was a person who provides wise counsel, prophetic predictions, or precognition of the future (as...

Oracle Fn - Serverless for the Enterprise

Oracle Fn - Serverless Computing for the Enterprise In other blog posts, I have talked about emerging technologies and, when I say emerging, I mean that they are are beginning to "cross the chasm" and become more widely used.    Serverless computing is gaining popularity because it allows developers to focus on the functionality of their code and not be worried about the target deployment environment. You could say it takes a lot of the "Ops" out of DevOps ;-) Developer's code can scale as needed automatically. Another advantage is that Serverless is elastic in its compute utilization which means you use compute resources only as they are needed in an on-demand fashion.    As Shaun Smith said in his blog introducing the project, Fn is a container native Apache 2.0 licensed Serverless platform that you can run anywhere–any cloud or on-premise. It’s easy to use, supports every programming language, and is extensible and performant. In that blog you learn that Fn is based on technology and a team that has been doing Serverless at scale both pre and post Docker. In fact, Docker is the only dependency. This is key because it means that developers can run Fn projects anywhere; different cloud providers, and even on their laptops for development.   For more background on why Serverless is important, see this article "What is Serverless Computing and Why is it Important" by Dylan Stamat from the team that helped create the Fn project.   For a enterprise-level technology to take off and become widely accepted, it needs to be open - that is a lesson we have learned since the earliest days of Java all the way through the numerous open source projects that have shaped the landscape. So, Oracle understands the power and usefulness of Serverless computing but, unlike some other vendors, does not believe that it should be proprietary. To the contrary, it should be open source.   To get an even more detailed look at why Oracle created the Fn Apache project, read "8 Reasons why we built the Fn Project" Chad Arimura - worth a read!   So, Serverless impacts Enterprise Architecture because it is a new model that needs to be worked into many companies ecosystem topographic maps and changes how enterprises need to support custom code in a very positive way. You can access the Fn open-source project/materials at GitHub              

Oracle Fn - Serverless Computing for the Enterprise In other blog posts, I have talked about emerging technologies and, when I say emerging, I mean that they are are beginning to "cross the chasm" and...

Rip Van Winkle and the Speed of Change of the Oracle Cloud Platform

A lot has been going on in the industry and at Oracle, and the pace is only getting faster! The Oracle Cloud Platform has evolved to a point that is so vastly different, deeper and differentiated (how's that for alliteration) that someone, who has not been consistently watching, would be shocked to see how things look now. Like Rip Van Winkle waking up to a different world, you'd be surprised at what has changed and wonder how these changes passed you by. The problem is that the rate of change is now so fast that, if you are not carefully watching on a monthly basis, you could feel "Rip Van Winkled" after just a few short months. It can happen that fast!                     Recently, Oracle has announced some really amazing new capabilities such as the Autonomous Database, Blockchain, support for Robotic Process Automation, and the new Serverless platform–Fn (see this great blog for more information: here). Here are just some of the sweeping architecture trends that one should really have their eye on. Each of them holds tremendous promise to help you drive differentiation and innovation in your company or agency. Artificial Intelligence/Machine Learning Robotic Process Automation (RPA) Serverless Computing Microservices Blockchain Unifying related cloud services into cloud platforms The 6th point in the list above is very important from a strategic standpoint. Oracle just released 2 major new services (DIPC and OIC). If you don't have your Oracle Acronym Decoder Ring© available, those stand for the Data Integration Platform Cloud and the Oracle Integration Cloud, respectively. What is important about these services, at the highest level, is that they both take what were delivered as stand-alone cloud services, and combine them into 2 integrated platforms where you don't spend time worrying about which tool to use, you simply start with what you want to do. In the past, you would say "Oh, I need to build an integration to SalesForce; guess I'd better use ICS." Likewise you might say, "I need to create a better, and automated, Employee On-boarding process; guess I should use PCS." Or you might say,  "I need to create a real-time data replication link between my on-prem database and a Cloud instance for reporting, guess I need Golden Gate." We have all been there, and that is how we solved problems in the past. f(x) = y; I need to do this (x), so I use that (y). Now you change your focus drastically away from a tool-focus to a focus on creating business value. Because both new platforms (OIC and DIPC) abstract away many of the details (such as selecting and deploying a new Cloud Service), you get immediate results and value from your efforts. That means you have more time to do what needs to be done -- and can start thinking of new ways to innovate on top of that. "What if instead of simply automating this process, we also enhanced the data reporting so business could get real-time reporting on Employee data across our geographically separate subsidiaries from a centralized 'source of truth'?" As an example, here are some of the things you can do with OIC: SaaS and On-Premises Integration: Quickly connect to 1000s of SaaS or on-premises Applications seamlessly through 50+ native app adapters or technology adapters. Support for Service Orchestration and rich integration patterns for real-time and batch processing. Process Automation: Bring agility to your business with an easy, visual, low-code platform that simplifies day-to-day tasks by getting employees, customers, and partners the services they need to work anywhere, anytime, and on any device. Support for Dynamic Case Management Visual Application Design: Rapidly create and host engaging business applications with a visual development environment right from the comfort of your browser. Integration Insight: The Service gives you the information you need -- out of the box, with powerful dashboards that require no coding, configuration, or modification. Get up and running fast with a solution that delivers deep insight into your business. Stream Analytics: Stream processing for anomaly detection, reacting to Fast Data. Super-scalable with Apache Spark and Kafka. This platform/capabilities approach is a huge step forward for Enterprise Architects who look, in ever increasing amounts, to technology to be in direct support of business needs and can't afford to be "Rip Van Winkled" by these recent trends wondering to yourself, "How did I miss this one?!?!" For more information, take a look at: OIC  Here is a video on YouTube: Overview Video DIPC I have highlighted them from the https://cloud.oracle.com page; select the "Platform" (API Platform highlighted because of my last article found here):        

A lot has been going on in the industry and at Oracle, and the pace is only getting faster! The Oracle Cloud Platform has evolved to a point that is so vastly different, deeper and...

API First - A Strategic Business Architecture

I took a break from blogging, but am back. So, for anyone who was following me in the past with greatest hits like "TOGAF Study Help - iPhone to the Rescue (perhaps)" and "Pats SOA Governance Perscription", I'm back. In my new role as Director of Business Development and Strategy, Oracle Cloud Platform - I still wear the hat of an Enterprise Architect all the time. That is to say, I help create and direct programs and strategy that are big-picture and cut across multiple domains and geographies. Sort of an Uber (not the car service company) Enterprise Architecture. So, with that re-introduction out of the way, today's topic is: API First - A Strategic Business Architecture! First off - there are some great blogs on this topic, and this is certainly one of the best out there (by Guy Levin on DZone) that explains the "how" to implement API-First. The article emphasizes that this approach fosters a strong foundation for enabling faster development and that (critically) you need to get the API contract right before teams all jump in as start using a particular API: What I have seen in my travels, talking with numerous different companies, managers and developers - is that they are beginning to see that API's are the doorway to innovation in this Age of Digital Disruption happening right now. If you were asleep or even just blinked, you might have missed the tsunami sweeping the corporate/business landscape, much like The Great Wave off Kanagawa. As mentioned in the article I referenced above, many large companies like Apple and Google are moving towards an API-centric strategy. When you look at your API's from a business-standpoint you see that they unlock opportunities and potential that would not be there otherwise. Why? Because API's are open, lightweight and easy to use - unlike any other integration approach of the past. Even SOA (in it's typical form) requires heavy-weight WSDL and SOAP - none of which fly with Mobile Developers or modern Application/Microservices Developers. The other HUGE area of innovation is opening up your core competencies and value-chain to partners, but in a light weight fashion that eschews the complexity of EDI. One of the best quotes I heard from someone I met in my travels recently is; "If it's not an API, it doesn't exist." This really drives home the point that older integration/access approaches are suddenly getting left behind. I will never say that SOA does not have merit, but if you don't have an API-First strategy in front of your SOA strategy, look out; you will get crushed by the tsunami of change before you have time to realize "what just happened?!?!". So, before you buy or build any new IT systems/applications, one of the first questions you need to ask is "How does this support our API-First strategy?" and "What new business opportunities can we leverage now that we have API's that we could not before?" With that lens, you start to see that business strategy decisions become predicated on the degree to which you have established your API strategy! The two become inexorably linked. Luckily, Oracle has you covered with the API Platform:  Oracle API Platform More on that in a future post. For now, I will leave you with the notion that you should begin thinking about what you could do, that you couldn't do before, if you had an API-Fist strategy in place. That is how you can make technology (API's/REST, etc..) super relevant to the business! But, you need to do it right up-front or you will miss the opportunity to ride the tsunami of Digital Disruption.          

I took a break from blogging, but am back. So, for anyone who was following me in the past with greatest hits like "TOGAF Study Help - iPhone to the Rescue (perhaps)" and "Pats SOA Governance...

Application Architecture

Solving the Polyglot Persistence Puzzle - Defining the Information Value Lifecycle

I believe an Information Architect’s primary purpose isto increase the value of the information assets belonging to anorganization. Securing and makinginformation available is no longer sufficient to grow the competitivecapabilities of an organization. Information architects must get: the right information to the right person at the right time in the right format so the best decisions can be made at all levels of theorganization. To assist Information Architects in understanding anddefining a process to increase the value of information assets, I have createdan Information Value Lifecycle map. Thisis the first step in understanding the characteristics of information on theway to building Polyglot Persistent Architectures. Building an Information Value Lifecycle map is done in 7steps. Step 1 – Build the Information Value Lifecycle maplayout. Each organization has multiple levels of decisionmaking. For each level of decisionmaking, there are Information Usage patterns and the Information Structuresneeded to support the usages. Theexample below starts with the Transaction Owners, the staff that create,maintain and own the transactions required to run the business. At the highest level are the CEO and Board ofDirectors (BoD). Maps will differ toreflect each organization’s hierarchical process of decision making. Step 2 – Define the Information Usage patterns and theInformation Structures needed to support the Information Usage pattern. Typically different levels of decision making requiredifferent levels of aggregation and summarization of information – from simpletransaction reporting to cross line of business and industry aggregations, analytics and predictive analysis. Information architectures over the years haveevolved well know sets of information structures (most commonly 3rdNormal Form, Star, Snowflake and Cube schemas) needed to support these UsagePatterns. Step 3 – Define the processes needed to transform andaggregate information from transactions to the highest level of the decisionmaking process. Extract, transform and load (ETL) processes moveinformation from one level of decision making to the next based on theinformation usage patterns. Mappingthese ETL process at a high level ensures data linage is understood andinformation accuracy is guaranteed. Someapplications provide capabilities that ‘jump’ the information past some levels tothe highest levels of the decision making process. Oracle Hyperion is an example. Step 4 – Record Master Data Management usage patterns Understanding Master Data usage patterns gives insightsinto which types of information are most important to an organization. They also indicate the level of informationmanagement maturity – more usage of master data reflects an understanding ofthe value of master data and a willingness to invest to realize that value. Step 5 – Identify Big Data usage patterns Most organizations have begun the process of deployingand realizing the value of Big Data. RecordingBig Data usage patterns shows the maturity of an organization in relationshipto their ability to adopt and deploy new technologies. Step 6 – Identify the ‘Gold Nuggets’ in Big Data Identify where Big Data data mining and analytics hasincreased the quality and/or quantity of information inputted into the InformationValue Lifecycle. These processes arecommonly referred to as finding the ‘Gold Nuggets’ of information that were previouslynot known. It’s important to understandthe value of the ‘Gold Nuggets’ in the decision making process of anorganization to justify the level of effort and expense of deploying Big Dataarchitectures. Step 7 – Identify new Big Data information valueopportunities The low cost of some Big Data architectures has allowedorganization to capture new sources of data that have lead to new ways of doingbusiness. Many of these use casesinclude social media as a way of judging the success of marketing campaigns andnew product lunches. Capturing these BigData opportunities shows the agility and innovativeness of an organization. In the next blog I will introduce the 16 Information Characteristics that make up the heart of the Information Characteristics Architecture Method.

I believe an Information Architect’s primary purpose is to increase the value of the information assets belonging to an organization. Securing and makinginformation available is no longer sufficient...

Information Architecture

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.   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.

Solving the Polyglot Persistence Puzzle- Using the Oracle Information Characteristics Architecture Method Polyglot – Knowing or using several languages.Persistence – A coding technique or technology...

Technology Architecture

Your Next Business Transformations will require a Hybrid Cloud Architecture

This posting represents highlights of the upcomingpresentations at the annual Oracle ECA Summit, October 27 at Oracle OpenWorld.  Talk to your Oracle account manager for aninvitation - Today! The public cloud has typically been outside of the domain ofenterprise architects. On the surface, it has been considered an external silowhere procurement decisions have been driven by line of business executives. But not anymore. Business processes extend into thecloud. And, the cloud extends into theenterprise. However, this state of affairs is changing rapidly ascustomers increasingly embrace cloud computing. Enterprise architects arecalled on not only to review public cloud implementations but also tounderstand how best to integrate new cloud offerings with existing on-premisesinformation systems. Most companies will have a combination of assets combiningpublic cloud SaaS, PaaS and IaaS with their existing on-premises systems. Themarketing folks are calling this Hybrid IT. Enterprise architects therefore face a new set of challenges as theyfigure out how to integrate these systems with each other. Today's enterprise architects face a shifting set ofcircumstances. In the next two years, a growing number of companies plan tomove key parts of their computing workloads to public clouds to take advantageof lights-out automated software provisioning and management, rapid projectimplementation, elastic scalability, and subscription-based pricing models. Tokeep up with consumer demand, IT has become an external service broker. In somecases IT pros have been forced to support heterogeneous cloud "silos"that may have proprietary methods of security, integration, management, andgovernance. These trends are forcing core IT departments to formalizeenterprise governance and enterprise architecture to mitigate risk. Oracle ECA Summit Agenda  The Oracle Enterprise Architecture team has helped a numberof 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, threecustomer architects will speak to their experiences in building these nextgeneration platforms. Seethe 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, Oraclewill clarify the requirements and plans for Oracle’s enterprise-class and productionworkload cloud services.  Last year,Thomas Kurian, President, Development, Oracle also spoke to the landscape of technology cloud services. Youcan 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 aninvitation - Today!

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...

IT Strategies from Oracle

Is Database-as-a-Service in your IT Services Catalog?

Are You Ahead or Behind theCurve? Private Database Cloud Services or Database as a Service(DBaaS) is no longer a new idea. Infact, it is quickly becoming the de facto standard for development and testingenvironments both on premises and in the public cloud. And while there are many use cases anddeployment options, overall database total cost of ownership and businessagility have benefited from a standardized approach to workloadmanagement. Whether you are a DBA, anoperations manager, or a CIO, you are well aware that business-driven interestin social, mobile, big data, and internet of things have caused an explosion ofdevelopment, data, and database workloads. The justification for database operations to pool resources andstandardize services has never been clearer – watch thiscustomer story (TRT1:30). Today’s best practices in cloud architecture expect serverscalability, zero data loss resiliency, and most importantly workload securityand isolation through multitenancy. For database services, the architecturewould be incomplete if database operations did not also natively supportmultitenancy. Initial approaches for DBaaSwere limited since they only relied upon virtual machines for workloadisolation and database provisioning. As general technology containers, VMs hadno intrinsic understanding of database operations, so they were unable to optimizeperformance, scalability, and resilience as well as simplify databaseadministration efforts. Today’s best practice for database cloud services overcomesthese limitations. The Oracle PrivateDatabase Cloud approach is both revolutionary and elegantly simple. By engineering multitenant capabilities throughoutthe Oracle database platform, the complete range of database operations andadministration can now be natively managed andwithout the overhead of a virtual machine. Oracle’s Private Database Cloud guarantees isolation and leveragesOracle’s strengths in reliability, scalability, security, and systemsmanagement. Large database estates also benefit from a host of relatedcapabilities, such as cost-recovery reporting, self-service management, andpublic cloud integration. You will findthat Oracle database platform is ideal for a standardized enterprise deploymentor cloud service, whether development/test or production – watch thiscustomer story (TRT2:17). Oracle offers a reference architecture overview and Oracleproduct mapping for DBaaS in a private cloud deployment model. The approach and guidance offered is thebyproduct of hundreds of customer projects and highlights the decisions thatcustomers faced in the course of their architecture planning andimplementations. Oracle’s advisingarchitects work across many industries and government agencies and havedeveloped standardized methodology based on enterprise architecture bestpractices. Oracle’s enterprise architecture approach and framework are articulatedin the Oracle Architecture Development Process (OADP) and the Oracle EnterpriseArchitecture Framework (OEAF). Click here for an Enterprise Architecture approach to the Oracle Private Database Cloud Table of contents: Executive Summary 1 Fundamental Concepts 2 What is a Private Database Cloud andDatabase as a Service? Why Consider Database as a Service? What is Different about Database as aService? Considering Moving to Database as aService? Architectural Perspectives 5 Architecture Principles DBaaS Architecture Domains Architecture Views 8 Conceptual Architecture Overview DBaaS Management Capabilities andProcess Overview DBaaS Physical Architecture Conclusion

Are You Ahead or Behind the Curve? Private Database Cloud Services or Database as a Service (DBaaS) is no longer a new idea. Infact, it is quickly becoming the de facto standard for development and...

EA Governance

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!

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...

EA Governance

Soft Skills, Leadership, and now Empathy

A recent post by @mikejwalker on a new Soft Skills course by Architecting the Enterprise rightly points out the importance of soft skills for the EA discipline. I think this is a great addition to the profession and shows formal recognition of the importance of soft skills in the industry. The EA positions I've seen in companies are generally at a 1st or 2nd line management grades. Corporations seem to recognize at some level the need for a "higher stature" for the EA professional. The leadership skills take more cultivation than just updating the HR records, however. It takes a skillful balance of things perhaps even learned outside the scope of the office such as running a youth organization or planning other non-profit events. Corporations are wise to invest in leadership training - often only slated for management - for EA professionals.  The EA profession is both strategic and change-oriented impacting people far more than the bucket of bolts on your data center floor. Changing behaviors in humans is at the core of the discipline.  The above was written last week. This week @nickmalik rightly opines on the importance of empathy EAs. I only scanned this article (which deserves a good read by the fire with my favorite scotch). He's definitely onto something here... Bottom line - soft skills are becoming increasingly important!!! So, fellow EA professional, what do you do to hone your soft skills? Who do you draw upon for leadership lessons?

A recent post by @mikejwalker on a new Soft Skills course by Architecting the Enterprise rightly points out the importance of soft skills for the EA discipline. I think this is a great addition...

EA Governance

RACI Matrices, EA Charters, and Surgical Suites

In another moment of (over) thinking enterprise architecture, I was comparing the surgical suite to a project team. I'll define a team as a committee, or other ad-hoc group of individuals engaged in a particular task. While the surgical team has many members, they all play a specific role. And some, such as medical students, may be spectators viewing from above. In the surgical suite, folks know their roles. Students in the gallery know they are to take notes and not scrub in. Those perform procedures are not scribbling in their notebooks either. Everyone knows their part - before going into the surgery. A common tool used within organizations to delineate roles and responsibilities is the RACI matrix. It simply describes the subject area along with levels of responsibility for the particular subject mapped to an organization unit, committee, or individual. While individuals may agree or disagree with the contents of the RACI matrix, at least its explicit and people can collaborate around it. Like RACI matrices,  EA charters provide a level of clarity for EA programs in terms of the services they provide and what they don't provide. Composing a RACI matrix helps identify the various roles interacting with an EA program and who weighs in at what level for a particular concern.  For your EA program, do you have a formal charter? Does it include a RACI matrix? How do you delineate responsibilities in a centralized or federated EA environment? 

In another moment of (over) thinking enterprise architecture, I was comparing the surgical suite to a project team. I'll define a team as a committee, or other ad-hoc group of individuals engaged in a...

EA Processes

Basic is Best

Fellow foodies will recognize the recent movement towards "farm-to-table" restaurants. These venues attempt to simplify their menus and source ingredients as close to the source as possible. I had the opportunity to dine at such a restaurant the other evening. I was gushing about the appetizer to my server when she described the preparation for the item and then punctuated her comments with "basic is best". I reminded my fellow enterprise architect diners there was an architecture lesson in that statement. They rolled their eyes and chuckled. But they also knew I was right. I'm reminded of Frederick Brooks' book The Mythical Man Month and his latest The Design of Design. The former must read book talks about complexity. But he refrains from damning all complexity. The world we live in and enterprises we strive to transform with enterprise architecture are complicated organisms, much like the human body. But sometimes a simple solution is the best approach. Fewer applications (think: portfolio rationalization). Fewer components. Fewer lines of code. Whatever level of abstraction you are working at, less is more. I'm reminded of the enterprise architecture principle "Control Technical Diversity". At one firm I created pithy catch phrases for each principles. I named this one "Less is More". But perhaps another variation is what my server said the other night, "Basic is Best".

Fellow foodies will recognize the recent movement towards "farm-to-table" restaurants. These venues attempt to simplify their menus and source ingredients as close to the source as possible. I had the...

Application Architecture

Current State EA: Focus on the Integration!!!

A recent project has me at the front end of a large implementation effort covering multiple software components. In addition to the challenges of integrating 15-20 separate and new software components there is the challenge of integrating the portfolio into an existing environment. Like other clients I've worked with and other environments I've worked in for many years, this is typical. The applications are undocumented and under patched leading to a mystery for any architect leading change.  We can boil down most architecture development methodologies (ADM) into first understanding the current/baseline state and then envisioning one or more future states. Many pundits emphasize the need to focus on the future/target states. I agree since enterprise architecture (EA) is about where you are going and not so much where you have been. But to be effective in the future, I contend some focused time needs to be spent on the current state. And specifically on the integration. Integration is always the difficult part of a project (I might put it more coarsely at a cocktail party). While I don't have a case study, my anecdotal experience suggests poorly integrated application portfolios tend to cost more to operate and create entropy when trying to respond to new changes and opportunities. In the aforementioned project, I was able to get one of our EAs assigned to focus on just integration almost immediately. While we're still early in the process, this EA is uncovering all sorts of information that will greatly assist our future state planning for this solution. This information is driving early decision making that we anticipate will accelerate our efforts moving forward. #next_pages_container { width: 5px; hight: 5px; position: absolute; top: -100px; left: -100px; z-index: 2147483647 !important; } #next_pages_container { width: 5px; hight: 5px; position: absolute; top: -100px; left: -100px; z-index: 2147483647 !important; } #next_pages_container { width: 5px; hight: 5px; position: absolute; top: -100px; left: -100px; z-index: 2147483647 !important; } #next_pages_container { width: 5px; hight: 5px; position: absolute; top: -100px; left: -100px; z-index: 2147483647 !important; }

A recent project has me at the front end of a large implementation effort covering multiple software components. In addition to the challenges of integrating 15-20 separate and new software components...

Application Architecture

The Application Architecture Domain

I have been spending a lot of time thinking about Application Architecture in the context of EA. More specifically, as an Enterprise Architect, what do I need to consider when looking at/defining/designing the Application Architecture Domain?There are several definitions of Application Architecture. TOGAF says “The objective here [in Application Architecture] is to define the major kinds of application system necessary to process the data and support the business”. FEA says the Application Architecture “Defines the applications needed to manage the data and support the business functions”.I agree with these definitions. They reflect what the Application Architecture domain does. However, they need to be decomposed to be practical.I find it useful to define a set of views into the Application Architecture domain. These views reflect what an EA needs to consider when working with/in the Applications Architecture domain. These viewpoints are, at a high level:Capability View: This view reflects how applications alignment with business capabilities. It is a super set of the following views when viewed in aggregate. By looking at the Application Architecture domain in terms of the business capabilities it supports, you get a good perspective on how those applications are directly supporting the business.Technology View: The technology view reflects the underlying technology that makes up the applications. Based on the number of rationalization activities I have seen (more specifically application rationalization), the phrase “complexity equals cost” drives the importance of the technology view, especially when attempting to reduce that complexity through standardization type activities. Some of the technology components to be considered are: Software: The application itself as well as the software the application relies on to function (web servers, application servers). Infrastructure: The underlying hardware and network components required by the application and supporting application software. Development: How the application is created and maintained. This encompasses development components that are part of the application itself (i.e. customizable functions), as well as bolt on development through web services, API’s, etc. The maintenance process itself also falls under this view. Integration: The interfaces that the application provides for integration as well as the integrations to other applications and data sources the application requires to function. Type: Reflects the kind of application (mash-up, 3 tiered, etc). (Note: functional type [CRM, HCM, etc.] are reflected under the capability view). Organization View: Organizations are comprised of people and those people use applications to do their jobs. Trying to define the application architecture domain without taking the organization that will use/fund/change it into consideration is like trying to design a car without thinking about who will drive it (i.e. you may end up building a formula 1 car for a family of 5 that is really looking for a minivan). This view reflects the people aspect of the application. It includes: Ownership: Who ‘owns’ the application? This will usually reflect primary funding and utilization but not always. Funding: Who funds both the acquisition/creation as well as the on-going maintenance (funding to create/change/operate)? Change: Who can/does request changes to the application and what process to the follow? Utilization: Who uses the application, how often do they use it, and how do they use it? Support: Which organization is responsible for the on-going support of the application? Information View: Whether or not you subscribe to the view that “information drives the enterprise”, it is a fact that information is critical. The management, creation, and organization of that information are primary functions of enterprise applications. This view reflects how the applications are tied to information (or at a higher level – how the Application Architecture domain relates to the Information Architecture domain). It includes: Access: The application is the mechanism by which end users access information. This could be through a primary application (i.e. CRM application), or through an information access type application (a BI application as an example). Creation: Applications create data in order to provide information to end-users. (I.e. an application creates an order to be used by an end-user as part of the fulfillment process). Consumption: Describes the data required by applications to function (i.e. a product id is required by a purchasing application to create an order. Application Service View: Organizations today are striving to be more agile. As an EA, I need to provide an architecture that supports this agility. One of the primary ways to achieve the required agility in the application architecture domain is through the use of ‘services’ (think SOA, web services, etc.). Whether it is through building applications from the ground up utilizing services, service enabling an existing application, or buying applications that are already ‘service enabled’, compartmentalizing application functions for re-use helps enable flexibility in the use of those applications in support of the required business agility. The applications service view consists of: Services: Here, I refer to the generic definition of a service “a set of related software functionalities that can be reused for different purposes, together with the policies that should control its usage”. Functions: The activities within an application that are not available / applicable for re-use. This view is helpful when identifying duplication functions between applications that are not service enabled. Delivery Model View: It is hard to talk about EA today without hearing the terms ‘cloud’ or shared services.  Organizations are looking at the ways their applications are delivered for several reasons, to reduce cost (both CAPEX and OPEX), to improve agility (time to market as an example), etc.  From an EA perspective, where/how an application is deployed has impacts on the overall enterprise architecture. From integration concerns to SLA requirements to security and compliance issues, the Enterprise Architect needs to factor in how applications are delivered when designing the Enterprise Architecture. This view reflects how applications are delivered to end-users. The delivery model view consists of different types of delivery mechanisms/deployment options for applications: Traditional: Reflects non-cloud type delivery options. The most prevalent consists of an application running on dedicated hardware (usually specific to an environment) for a single consumer. Private Cloud: The application runs on infrastructure provisioned for exclusive use by a single organization comprising multiple consumers. Public Cloud: The application runs on infrastructure provisioned for open use by the general public. Hybrid: The application is deployed on two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability. While by no means comprehensive, I find that applying these views to the application domain gives a good understanding of what an EA needs to consider when effecting changes to the Application Architecture domain.Finally, the application architecture domain is one of several architecture domains that an EA must consider when developing an overall Enterprise Architecture. The Oracle Enterprise Architecture Framework defines four Primary domains: Business Architecture, Application Architecture, Information Architecture, and Technology Architecture. Each domain links to the others either directly or indirectly at some point. Oracle links them at a high level as follows:Business Capabilities and/or Business Processes (Business Architecture), links to the Applications that enable the capability/process (Applications Architecture – COTS, Custom), links to the Information Assets managed/maintained by the Applications (Information Architecture), links to the technology infrastructure upon which all this runs (Technology Architecture - integration, security, BI/DW, DB infrastructure, deployment model).There are however, times when the EA needs to narrow focus to a particular domain for some period of time. These views help me to do just that.

I have been spending a lot of time thinking about Application Architecture in the context of EA. More specifically, as an Enterprise Architect, what do I need to consider when...

Application Architecture

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

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...

Business Architecture

Cloud and IT Organizational Change

Recently, I was involved in the development of the Database as a Service reference architecture.  In developing the business and IT capabilities models, I defined Service Design and Development as required IT functions for the delivery of cloud services.   This provided us the basis for establishing and managing the business service and technology service catalogs.  In order to effectively define the technology requirements, we needed to have a process to capture the characteristics and attributes of the database services to be delivered through a cloud model.   We had to incorporate appropriate Service Levels and Quality of Service options as well.Once those were defined, we needed to develop technical capabilities for hosting the deployable services, along with the management of the resources and the deployed instances owned by the consumers.  The service development function was responsible for not only the packaging of the database deployment objects, but the processes and technology for service deployment, monitoring and administration.  We looked to ITIL for guidance in defining the process for establishing the service strategy, service design, and the service operations, as well as the configurations of the resources hosting the consumer’s database service instances.  After working on the reference architecture, I had a question – is this now an IT Capability or a series of process that IT follow?, Does the deployment of Database Services through a Private Cloud model require the IT Organization to change structurally, or do we apply the ITIL Process Framework on top of the existing IT Organization?  The framework is certainly flexible enough to support a variety of organizational and operational structures.  I am not suggesting that the IT Structure needs to change in a dramatic way to begin to take advantage of this new capability.  However, the ability to effectively develop the skills and experience in developing and delivering cloud services would be positively enhanced and matured through a dedicated practice within the IT organization.  This would not be dissimilar to developing Centers of Excellence for SOA or Business Intelligence. What are your thoughts and experience?  Should a Service Architecture Design and Development be a capability supported by its own function in the IT Organization?  Should a Cloud Center of Excellence be implemented through the IT organizational structure, or a virtual organization based upon a policy and process framework?   How would this best be applied in organizations with distributed IT funding models?        

Recently, I was involved in the development of the Database as a Service reference architecture.  In developing the business and IT capabilities models, I defined Service Design and Development as...

Business Architecture

How Strategic is IT? - Assessing Strategic Value

Why do we care?  Understanding the role IT plays in the business will be important in establishing proper scope, obtaining support for initiatives and delivering the greatest value to the organization.  Recently I was working on strategies for Data Center Transformation.  The challenge was a scope focused on the technology domain during the Architecture Vision Phase.  How do we create alignment to the broader business architecture, when the drivers and KPIs tend to be tied almost exclusively to IT operating and capital expenses, or an idea of supporting business agility?I was concerned that the technology architecture strategy that I was defining was too vague and treated IT as if it was applied monolithically - Standardize, Consolidate, Optimize.  I looked to Strategic Significance as a way that I could potentially provide a more nuanced technology strategy, that took into consideration that IT has more strategic significance to different parts of the organization.Taking a broad brush approach – we could imply that IT is strategic to almost every modern business.  That being without IT capabilities much of the organizations functions would come to a halt.  However, what we really are looking at is most likely a wide-ranging application of tactical capabilities applied across the different business functions.  So, in this light, IT is as Strategic as a reliable Electric provider.I think it is fair to say, that the Business Leaders assume that competent facilities people will keep the lights on, just as IT will keep their processes rolling along.  So, how strategic is IT?What is Strategic ValueStrategic Value is about Competitive, Pricing, Cost, Product or Market Differentiation.  Wal-Mart’s strategy touches on three of these – Pricing and Cost are talked about widely.  Being the low-cost leader establishes a unique place in the market.  The can achieve this through their cost strategy, influence upon suppliers and the generation of Wal-Mart specific low-cost products based upon their buying power.  Finally, geographic spread – Wal-Mart is everywhere, is a part of a Market dominance strategy. Strategic Relevance – When IT "Is the Value Chain"So, when does IT take on the role of a Strategic Differentiator?   Ever here of Google or Amazon? There product is IT.  This is a bit of an extreme example, but the point is that the closer IT is to the Product or Service the more strategic it's value is to the organization.  In the absence of Information Technology what would their product be?  Even within the Amazon example, you can not diminish the capabilities that they have developed around order fulfillment.  This includes a lot of manual picking and packing, and they are very efficient in how they have implemented this capability.  However, if it was not for their ability to reach customers and match customers to products via the Web, they become a catalog retailer of the 1950’s.Strategic Relevance – When IT is a "Part of the Value Chain"When else do we see IT as providing Strategic Value?  A Recent story about Target and their customer targeted marketing has been in the news.  This is how Target uses Predictive Analytics to selectively market to individual customers based upon their buying habits and trends, in conjunction with some very sophisticated algorithms.  This allows Target to maintain mindshare and attract new customers, which they claim provides them with about a three-year attachment run.  Here we see this Predicative Analytics playing a significant role in Targets Marketing Strategy.  The capability is core to their Marketing approach for customer capture and retention. So Strategic Value can be identified on broad terms where IT is the Business or as specific functional segments within the business.  The importance is how close the IT capability is to the actual fulfillment of the business strategy.  Both Amazon and Target see IT as strategic; it is just a matter of scope.  I am sure they both have General Ledger and HR Systems, but do those IT capabilities provide strategic differentiation?Technology Archtiecture Strategy - Data Center Transformation So, if I am in an EA Engagement establishing the Architecture Vision and my scope is the Technology Domain, what are some of the tools I can apply to assess the strategic significance?A reasonable place to start might be at the Business Architecture.  We need to establish our understanding of the Capabilities and Processes that drive the business.  Paul Silverstein has developed some useful models for evaluating business value vs. business scope – how much value the organization receives versus how broadly a capability or process impacts the organization.  Funding Models might be a useful piece of the puzzel as well.By individually, assessing each capability we can define them in terms of tactical impact and strategic impact.  Next, we can evaluate each from the perspective of IT support required to deliver the capability.  We can start with the organizational alignment of IT and the business function to see to what extent the IT function is integrated within the business capability. Where there is tight alignment, we might want to highlight that capability for further analysis within the Architecture Vision Phase.  Funding models may provide us with insight concerning the functions dependencies on IT, and how much control the business function maintains over their IT capabilities.Often we use Strategy Maps, and they provide value.  But what if I want to refine the assessment in order to establish tighter line of sight between functional stategies and IT.  I have seen some examples of balanced scrore cards used in assessing IT's relative value, but it tended to be applied very broadly.    I am suggesting that by assssing IT significance to the individual business function strategies in scope, we may be able to define a technology architecture strategy that focuses where the different standardization, consolidation, and optimization strategies will be most impactful, and return the greatest value.Models and Tools for refining Strategic Alignment and Significance?Are there tools you use for IT Strategic Assessment? I would be interested in hearing how you define the role of IT within your customer’s organizations, and how they determine strategic significance?  “Leveraging the New Infrastructure”, a book from Peter Weill and Marianne Broadbent, has some very interesting models depicting IT Investment to IT Impact.    Do you have models or re-purpose models such as Balanced Score Cards to focus on IT value and strategic significance?  Are there specific metrics that you or your customers find useful in defining strategic signifcance?  

Why do we care?  Understanding the role IT plays in the business will be important in establishing proper scope, obtaining support for initiatives and delivering the greatest value to the...

EA Governance

Pats SOA Governance Perscription

 Just recently, I was asked to provide some advice to a customer on how to adopt SOA Governance, specifically the Oracle Enterprise Repository (OER), in a step-wise and rational way.  It seemed like sage enough advice to publish hereHere is what they were trying to do which is similar to what other customers are doing:Establish a single source of truth in a SOA Repository Single repository supporting on-shore / off-shore distributed teams Manage service artifacts (i.e. projects, service design documents, policy definition…) Enables SOA program managers manage service portfolio and service demands Enables SOA program managers with related reports (i.e. demand, reuse, compliance & exceptions, dependency/impact analysis, …)So it can be successful - but you don't want to boil the Governance Ocean - at least not all at once.  In a word, I’d advise getting a firm understanding on which services you want to govern (probably not all of them) and the types of things you want Governance to do for you. Once you have that, you can move forwards in a stepwise approach that reduces the effort AND complication.  Realize that installing OER is only a small part of the puzzle.  You need to have the right Org structure (official or unofficial) in place and the right incentives and rewards to help motivate people to “do the right thing” such as to reuse services instead of writing their own.  Then you need the right processes to for people to follow.  It’s the notion that:    Governance = PEOPLE + TECHNOLOGY + PROCESSESLet’s say there are 50 key services to manage -  for discussion purposes.  Here is what I’d do at a super high level:Add Projects, Policies, Classifications Asset Types as needed (JUDISIOUSLY – keep it simple at first)Add users in different rolesGet your top 50 key existing web services in OER using the Harvester if possible.  Otherwise just take some time to add them manually.  Make sure these are the relatively static PROXY services from OSB.Be sure to assign one or more people to OSR as administrators/architects to help keep things in order Add the correct lifecycle stage to themAdd the right classifications/taxonomy to themAdd documentation such that developers know how to use the service (i.e. can download a doc or visio or whatever that explains it)Add any and all XSD, WSDL and other files that people would need to download to actually use serviceAdd a section to the OER home page that explains to users about the WL Gore SOA program, schedules and contacts – make it a place people go for some critical PROGRAM-level information – SELL what you are doing here…Get developers used to using the tool through an in-house trainingUse the reports to get a management view into the SOA program and help fund/support what you are doingThen – start entering future state services to track as they go from inception to deployment in the life-cycle Things that add complexity that you can add later IF they add value to what you are trying to do:Install OSR / set upEnable publishing to OSRSet up harvesting of SOA/BPEL projectsSet up/enable automated approval workflowsSynch up performance metrics from OSB or OEM back into OERAssign CAS (custom access settings) settings to individual assetsAnd so on.  But add these later after the basics are down.So - I hope this helps anyone else who wants to begin a SOA Governance effort using OER (with OSR, OSB and OEM as secondary stages after initial success).

  Just recently, I was asked to provide some advice to a customer on how to adopt SOA Governance, specifically the Oracle Enterprise Repository (OER), in a step-wise and rational way.  It seemed like...

Technology Architecture

Enterprise Architecture vs. SOA Architecture Part III

It's nice (and humbling) to know that people read one's blog.  I got a note from a reader that said: "I understand that SOA is more concerned with business services integration and EA is concerned with dealing with enterprise-level infrastructure and business components. If you could, would you be able to provide a brief definition of them both in your own words that clearly distinguish the differences? (that's different from my one?)" Good question.  SOA, I'll give it a try (forgive the pun).  This is strictly off the cuff, my cuff, recognizing that there are plenty of places to dig up various definitions of the two. Enterprise Architecture - The documenting and mapping of corporate strategic initiatives and strategies to the technological underpinnings that need to be in place to optimally deliver on those strategies.  What makes EA more than an intellectual or academic exercise is that it provides the governance scaffolding to ensure that the required work gets done to plan and deliver on required/key IT products/services/capabilities.  Importantly, EA is not focused on any one technology or technology bucket in isolation, but how they work in consort to ultimately provide business capabilities.Service Oriented Architecture – An architectural approach to creating software applications and system integrations which focuses on the notion of Services; reusable software components that leverage open standards.  This provides a vehicle for companies to create applications more rapidly than ever before through composite service assembly/orchestration.  Because they are Service-based, they are, at the same time, more flexible. Though SOA itself has nothing to do with any specific technology (it is architecture and an approach), Service creation/assembly/orchestration is often enabled through technologies such as Java, XML, and Web services.Is that useful?

It's nice (and humbling) to know that people read one's blog.  I got a note from a reader that said: "I understand that SOA is more concerned with business services integration and EA is concerned with...

IT Strategies from Oracle

Carpe Nube*

Enterprise Architecture is more important than ever with the increased adoption of Cloud Computing.  Most companies that I work with have a range of systems and initiatives that span the continuum of “must stay in house” to “this is best run in the public cloud.”  There are 3 types of Cloud Models:Private Cloud (we like cloud, but need to manage it ourselves because of security/cost/agility/etc.. reasons) Public Cloud (here are the systems we need, we will pay you to run it for us) Hybrid Cloud (some systems we need to keep in-house but for other stuff it would be cost effective (or cost avoiding)  if we did not have to run/maintain them ourselves)In all cases, Cloud is an IT operational model (what systems run where) that is driven by business needs and imperatives.  Even if you go 100% Public Cloud, you still need to make sure that the Applications and Information provided by those systems are meeting the ever changing business needs.  The Hybrid Cloud model provides even more complexity because applications, communication, integration, data flow, and security need to be coordinated across the Cloud boundaries.  Enterprise Architecture is the glue that can help keep all of these things together and is why Cloud Computing does not get rid of the need for EA, in fact, it is this humble author’s opinion that it dramatically increases the need of EA stewardship over Cloud.* (Latin for Seize the Cloud)

Enterprise Architecture is more important than ever with the increased adoption of Cloud Computing.  Most companies that I work with have a range of systems and initiatives that span the continuum of...

EA Processes

Enterprise Architecture Tools; Another View

Eric Stephens, my friend, and fellow Oracle Enterprise Architect, recently blogged on the subject of “Tools of the Trade” of Enterprise Architecture.   I was invited to the same podcast as he was, but could not attend.  So, in absentia, I thought I’d add my two cents to his sage post:(http://blogs.oracle.com/enterprisearchitecture/entry/tools_of_the_trade)There are several very good EA tools on the market, but each come with their own learning curve and, as Eric mentioned, there can be variance in usage across companies - ranging from no standardized EA-specific tools to adoption of one such as Troux.Having said that, here are the tools that I think are basic / fundamental in an Enterprise Architect’s tool box and how they can be used (or at least how I use them).  Idea is to embrace, but extend what Eric said. ToolUseSpreadsheet (such as, but not limited to Excel)Capturing everything about the project such as organization structure, divisions, current costs, etc…).  Once it is in the spreadsheet, it can be sliced and diced and, importantly, imported into the presentation software to make clear the facts that went into the current/future state positioning.  Also key to making a business case for any initiatives to be undertaken.Presentation Software (such as, but not limited to Power Point)Communication, communication, communication!  Getting everyone on the same page through information roll-ups, diagrams and architectures is really at the heart of what we do.  Yes?Oracle JDeveloper / BPMThis is great for sketching out a business process in BPMN notation which (unless you NEED a L0 – L2 model) is a pragmatic way to flesh out current and future state business flows.  The added benefit is that, with Oracle BPM 11g, Business Analysts and Developers can begin to collaborate on fleshing out your model once a business process automation project gets the go-ahead.Sure, you have to download a development environment but, hey, it’s free and relatively easy to use tool.Whiteboard Markers (such as, but not limited to Expo markers)Nothing works better than getting people in a room and working through a particular topic in a collaborative fashion.Hint from personal experience: make sure they are dry erase and not permanent.  Well organized file system (such as, well…you get the idea)The more you do this stuff, the more you have a library of tried and true materials that are battle tested.  Try to organize them well on your disk (or do what I do and catalog things in a spreadsheet with hyperlinks  to the files – one of my secret tricks)So, that is my story.  But, I may likely not stick to it....

Eric Stephens, my friend, and fellow Oracle Enterprise Architect, recently blogged on the subject of “Tools of the Trade” of Enterprise Architecture.   I was invited to the same podcast as he was, but...

EA Tools

Tools of the Trade

So recently my buddy over at OTN Bob Rhubart asked, “What tool or tools are indispensable in your role as an architect? When faced with a new project what's the first thing you reach for? Why?”. I instantly protested regarding the brevity of the answers. He suggested I blog about it. So here goes. So the Miss America answer is I “reach” for my eyes and ears. Listening to the customer’s needs and pain points is vital to ensuring a resultant architecture is in alignment with their business objectives and is attainable within their cultural milieu. I need to approach each engagement or initiative with a fresh, clean slate and record everything I hear or see. I can’t help but liken the job to that of an archeologist or crime scene investigator - especially when focusing on current state architecture. For practical tools I look to a metamodel to determine what type of information am I trying to collect. It depends on the corporation or framework I might be working with, but the metamodel provides me a sense of completeness in what I’m looking for. Its a great way to catalog current state observations and look for trends, redundancies, and sub-optimizations. When creating a set of future state renderings, it allows me to parse out future capabilities and map them to goals, drivers, and other objectives. So how do I track this information? I use Excel to track catalogs and matrices of the information in the metamodel. Optimally I would pump this information into a repository-based EA modeling tool like Troux, or MEGA. But not all EA programs have made the leap to these tools - many are still relying on PowerPoint/Visio (or OmniGraffle for us Mac folk). If I really need to do some extensive analysis - and its happened at least once - I’m able to export to CSV files and put them in a database and use my SQL-fu to come to an answer. As digital as I have become with an iPhone, iPad, and MacBook, I still rely on a bound notebook for taking notes - especially during customer conversations. The linearity of (spectacular) programs like Evernote, OmniOutliner, or even MindMap Pro just doesn’t work for me during discovery sessions. The information is not in a linear outline. I need to draw arrows all over the place. I need to instantaneously switch back-and-forth between writing text notes and drawing pictures. And batteries will eventually die or the flight attendant will bust me during takeoffs and landings… So there you go. A metamodel, Excel, and a good notebook. That’s my answer, Bob, and I’m sticking to it.

So recently my buddy over at OTN Bob Rhubart asked, “What tool or tools are indispensable in your role as an architect? When faced with a new project what's the first thing you reach for? Why?”. I...

Application Architecture

Vanilla Apps - An EA's Friend

Packaged Applications (such as PSFT, eBiz, etc…) are the very operational heart and soul of most companies.  Whether it is human capital management, logistics, sales, or any number of other fundamental applications - they are most valuable when they are customized to fit YOUR business and integrate with YOUR systems.  The problem is that these customizations and integrations are most often done with built in (proprietary) tools or using things like PL SQL, batch files or other less-than-optimal (often proprietary) solutions.Enterprise Architecture steps in at this point because the move from one major version to the next is a major undertaking for most companies; one that takes month (sometime as much as a year) to plan and implement.   When the applications have been customized to meet the business’s requirement, these very customizations make upgrading more complex.  One of the tasks of EA is to establish guiding principles which help shape decisions at every level of the architecture.  One key principle here is “Keep COTS Packages as Vanilla as Posible” – meaning do as little customization as possibly directly in the application itself.  The more vanilla the application is kept, the easier it is to upgrade.It is a best architecture practice to place these customizations in the middleware layer where standards such as Java, Web services, XML, and the like mitigate the risks of using proprietary technology.  They also provide a more comprehensive and faster-development-lifecycle framework for integrating with the entire corporate IT ecosystem while greatly enhancing the possibilities for service/integration reuse.So, with all that being said, a common question I get is “OK, where do we draw the line between using the built-in tools vs. using a middleware layer?”  This chart helps answer and provides delineation between the reasons to use one approach over the other.  Though not exhaustive, it should provide a framework for figuring out which customizations/integrations should go where. 

Packaged Applications (such as PSFT, eBiz, etc…) are the very operational heart and soul of most companies.  Whether it is human capital management, logistics, sales, or any number of other...

Application Architecture

Its always about the business (or mission)

So yesterday the follow-worthy @chrisonea lobs this question on Twitter: Is there any circumstance under which IT should build a thing without a business purpose? I emphatically answered, NO. Here's why. Long ago when the last of the punch card machines were dispatched to the junkyards and the IT department was still called Data Processing, I was in college. Being an IT wannabe, I enrolled in my first COBOL course. Dr. Barone was my instructor and took us through all that verbose quasi-English that produced reports on green bar paper in the lab. Aside from COBOL, he taught us a bit about the relationship between the business and IT. IT, he contended, exists to serve the business and not the other way around. He was rather emphatic about it. We were not at liberty to code our hearts out like some painter with a canvas. We were to fulfill requirements. Nothing more. Nothing less. Sir, yes sir! This idea has always stuck with me. Whether working in internal IT departments or producing software for external clients. Even in the latter case the software exists solely to achieve an objective for the client's business. It especially resonates well as I focus on enterprise architecture.  If I were to rationalize an IT portfolio of applications or middleware, I still rationalize at the behest of the business. There is a realizable benefit that can be articulated in business terms. Reduced operating costs through simplification in this case. Every CFO and CEO understands that language. Even if I were to "build it and they will come" (speculation), there would still be some business outcome I'm seeking such as revenue generation. Yes, ITs still about the business. Period.

So yesterday the follow-worthy @chrisonea lobs this question on Twitter: Is there any circumstance under which IT should build a thing without a business purpose? I emphatically answered, NO. Here's...

IT Strategies from Oracle

Combining SOA and WCM

A good friend of mine was in town this week to visit one of his clients.  When we got together for dinner (and, yes, drinks) one of the topics (inevitably) was architecture.  Lately he has been working with some very large international companies re-architecting their public web sites to flexibly deliver localized content.  The solution was to combine Service-Oriented Architecture with Web Content Management. In a nutshell, the architecture includes a web front end that is composed from portlets where each portlet requests content from WCM system(s) using WSRP.  The front end is de-coupled from the WCM systems via a service bus where the service bus is responsible for routing the content request to the appropriate WCM system.  (I’m using the term “service bus” here in the most generic sense, not to denote a specific product.  My friend prefers the term “service fabric”.) This has an obvious advantage for localized content.  The service bus routes the request to the correct WCM system based on the chosen local.  This allows each division, country, or geography to manage its own content yet the corporate web presence is still unified. Another advantage my friend pointed out is that this architecture simplifies previewing of new or modified content.  The service bus can route content requests to a staging WCM system for users that are responsible for reviewing new or modified content.  The new/modified content can be viewed directly in the production web site before being “published”. It figures that I’d have this conversation *after* writing the ORA User Interaction document (a part of ITSO).  Nonetheless the ORA User Interaction document does cover these topics albeit not this specific usage.  This architecture is a specific example of what is denoted generically as “federation” (e.g. section 4.2.3) in the document.

A good friend of mine was in town this week to visit one of his clients.  When we got together for dinner (and, yes, drinks) one of the topics (inevitably) was architecture.  Lately he has been...

Application Architecture

It's not the Journey, It's the Endpoints

In a recent discussion about Governance with some customers this week, an interesting subject came up.  They are well on their way with a SOA implementation and are beginning that the time to govern it is now.  This is not at all unlike *many* folks that I talk to.SOA is becoming more and more an important part of EA; in fact the SOA aspect of TOGAF is apparently getting majorly beefed up in the next implementation.  It is key because SOA is *not* a technology, but an architectural solution approach that is unique in its tie to providing business value.Anyway, back to the customer, they want to use dynamic service endpoints exclusively and eschew hard-coded endpoints entirely.  One of the chief benefits of Oracle’s OER/OSR (Repository/Registry) is the ability to harvest and manage service lifecycles to include publishing endpoints to the UDDI Registry and generating unique Service Key’s.  Once you have the Key, you can access the service by dynamically looking up the end point without having it baked into your code.  This provides a great deal of flexibility.I found a blog from Edwin Biemond that shows you how to use this Service Key as an indirection to the actual service from within SOA Suite.http://biemond.blogspot.com/2009/12/using-oracle-service-registry-in-soa.html“Look Ma’, no hard coded endpoints..” – from the blog it shows how the UDDI Inquiry API is used instead of a specific service location.  This spells flexibility.1.    <reference name="HelloService" ui:wsdlLocation="BPELProcess1.wsdl">  2.      <interface.wsdl interface="http://xmlns.oracle.com/HelloWorld/Helloworld/BPELProcess1#wsdl.interface(BPELProcess1)"/>  3.      <binding.ws port="http://xmlns.oracle.com/HelloWorld/Helloworld/BPELProcess1#wsdl.endpoint(bpelprocess1_client_ep/BPELProcess1_pt)"  4.                  location="orauddi:/uddi:d798e4c0-f4ab-11de-8e46-d0e4b9a18e45">  5.        <property name="oracle.soa.uddi.serviceKey" type="xs:string" many="false">uddi:d798e4c0-f4ab-11de-8e46-d0e4b9a18e45</property>  6.      </binding.ws>  7.    </reference>

In a recent discussion about Governance with some customers this week, an interesting subject came up.  They are well on their way with a SOA implementation and are beginning that the time to govern...

EA Processes

Incremental Progress in (EA) Strategy Execution

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Optima}p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Optima; min-height: 14.0px} I hate watching sports. Period. Except curling where I am confused yet fascinated all at the same time. Despite my aversion, I can still see lessons for EAs and those executing strategy. So here goes... Consider soccer and (American) football. In soccer, patterns and plays are improvised and executed very quickly. Goals are scored when you put the ball in the other team's goal. You run until you score, get hurt, or just pass out. That's about it. In football, plays are thought out, deliberated by an overstaffed sideline, and then executed. Incremental progress is measured in yards and downs. At some point, someone either kicks a field goal (3 pts) or moves the ball into the end zone (6 pts). The game moves slower and more deliberately than soccer. This is where I see the lesson. Regardless of EA methodology or framework, one needs to construct some sort of roadmap for their architecture. Otherwise, all those massive architecture diagrams are nothing more than 21st century art. The roadmap articulates the various steps an organization needs to execute in order to reach a target state in the architecture. There may be multiple target states before arriving to the next "future state". And within each target state there are incremental steps. Sometimes, its baby steps, and that is OK.  To paraphrase a previous tweet or blog post, EA (strategy execution)  is a set of executed tactics orchestrated to achieve a desired end state. EA programs should take great care to crisply define the target states and the incremental tactics used to achieve each target state. And, when those tactics or states are realized, examine closely if one is still on track and is moving forward. I always advocate the value of  "advancing 1 yard" on a project or other initiative regarding the architecture.  Sometimes, a yard is all you can get. Take it, and keep moving.

I hate watching sports. Period. Except curling where I am confused yet fascinated all at the same time. Despite my aversion, I can still see lessons for EAs and those executing strategy. So here...

EA Processes

Enterprise Climatologist?

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Optima}p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Optima; min-height: 14.0px} Some of us on Twitter (#entarch) were noodling around for alternative names for Enterprise Architects. Someone chimed in about using "meteorologist" and suggested "climatologist". Then I thought more about the definitions of these words and how these roles operate. These individuals work on massive amounts of historical data and seek patterns in nature to predict weather patterns and then issue forecasts. But at this point, the best we can do is react to the coming weather. If its a tornado, we head to the SW corner of the basement. If its a hurricane, we try to get out of town (at least most do). We cannot stop a tornado or steer it in a more favorable direction. And while there are proactive measures one can take to endure a storm and bolster structures, one cannot control or shape the weather.  And that is where the meteorologist/climatologist analogy breaks down for EA. EAs need to be strategic in their thinking and help clients shape their future, not solely react to enterprise events. Like the weather, there are forces (e.g., Porters Five Forces) that one cannot control and must formulate a response. But the EAs job is to provide a vision and executable plan to a desired end state. Smart EAs leverage the experiences of others in design patterns and strategy execution. The discipline of EA provides the way to proactively shape the future for an enterprise.  What are your thoughts? What lessons can EAs and the discipline of EA garner from other disciplines?

Some of us on Twitter (#entarch) were noodling around for alternative names for Enterprise Architects. Someone chimed in about using "meteorologist" and suggested "climatologist". Then I thought more...

EA Processes

Architecture in 4 Slides

I think Bruce's idea on an Architecture in 4 Slides is the right idea for presenting such material at the executive level. Often times the C-level crowd does not have the time, nor should they take the time, to digest all the details of the full architecture description. At the end of the day, the executive wants to know "how do I get to the future state". This usually means going to the fourth slide that describes the roadmap. I started doing some math, though, and realized that Bruce was only talking about Enterprise Technology Architecture. For those who think in TOGAFian terms, we have three other domains to describe. And maybe a 4-pack of slides each for security and SOA. So unfortunately the executive deck grows 4 slides at a time. But I think Bruce's idea is still sound. Each domain gets four slides. I think this approach is good for the boardroom. I think this executive deck is a derivation of more detailed models. Those who need to plan and ultimately implement the architecture need more detail. I've contended in other forums that one picture is insufficient to describe. One needs multiple views of an architecture (segment) in order to fully understand it. Secondly, pictures alone are insufficient. A description of the elements and rationale for decisions made is essential to make the architecture description actionable. I'm thinking of the standard formerly known as IEEE 1471 which advocates for multiple views based on the stakeholder and their concern(s). We the architects need to consider the audience of our work and tune it accordingly. This means multiple versions, levels, of detail, and notations perhaps to make our points.

I think Bruce's idea on an Architecture in 4 Slides is the right idea for presenting such material at the executive level. Often times the C-level crowd does not have the time, nor should they take...

The Power of Knowing Where You Are Going

; So, you might ask, what do Bruce Lee and EA have in common? Well, as a long-time martial artist and Bruce Lee fan, the connection should have been clear to me. But it wasn't. That was until a friend emailed me a link to a blog called "Letters of Note" edited by Shaun Usher. From the blog: When he wrote the following mission statement -- which, for argument's sake, I'm classing as a letter written to himself -- Bruce Lee was 28 years of age and a minor TV star in the United States, having featured in a number of shows which included, most notably, the ill-fated Green Hornet series. With his second child recently born and no financial security to speak of, the clearly determined founder of Jeet Kune Do decided to put his "definite chief aim" down on paper. The rest is history. (Read the original post: Letters of Note: My Definite Chief Aim.) The letter that Lee wrote highlights the power of knowing where you want to go and committing it to paper.  This is exactly what we do with EA.  We build a picture of where we want our company/agency to go and commit it to paper (or electronic files).  It is often said that, if you want to get something big done, write it down or tell a friend.  That way you are putting some skin in the game, as it were, and are more committed to the task at hand. So, a strategy is only as good as it is clear and documented - like Bruce's simple and single paragraph stating where he plans to go.

; So, you might ask, what do Bruce Lee and EA have in common? Well, as a long-time martial artist and Bruce Lee fan, the connection should have been clear to me. But it wasn't. That was until a friend...

Architecture Standards – BPMN vs. BPEL for Business Process Management

I get asked often which business process standard an organization should use; BPMN or BPEL?  As I explain to folks, they both have strengths.  Here is a great article that helps understand the benefits of both and where to use them.  The good news is that, with Oracle SOA Suite and BPM suite, you have the option and flexibility to use both in the same SCA model and runtime container.  Good stuff. Here is the great article that Mark Nelson wrote: The right tool for the right job BPEL and BPMN are both ‘languages’ or ‘notations’ for describing and executing business processes. Both are open standards. Most business process engines will support one or the other of these languages. Oracle however has chosen to support both and treat them as equals. This means that you have the freedom to choose which language to use on a process by process basis. And you can freely mix and match, even within a single composite. (A composite is the deployment unit in an SCA environment.) So why support both? Well it turns out that BPEL is really well suited to modeling some kinds of processes and BPMN is really well suited to modeling other kinds of processes. Of course there is a pretty significant overlap where either will do a great job What BPM adds to SOA Suite | RedStack

I get asked often which business process standard an organization should use; BPMN or BPEL?  As I explain to folks, they both have strengths.  Here is a great article that helps understand the...

IT Strategies from Oracle

ITSO - Behind the Scenes

This blog entry provides some "behind the scenes" commentary concerning the creation of the documents collectively known as IT Strategies from Oracle.There were three key concerns that the Oracle Reference Architecture (ORA) documentation approach needed to address:Define and document a single reference architectureSupport incremental delivery Ability to add new technology strategies as they emergeFor this blog entry I'll describe the approach and rationale for item number 1.A key concept built into ORA is that there is a single reference architecture. The more common approach is to create multiple different reference architectures, each focused on a particular set of technologies, which creates a problem when an IT environment needs to incorporate two or more of the disparate reference architectures. Rather than creating separate reference architectures, ORA addresses "sets of technology" via perspectives (e.g. SOA perspective). Each perspective provides a view of ORA focused on a particular set of technology.This may seem like simply semantics, but the ramifications of this approach are actually far reaching. First, following the single reference architecture approach required that all the documents follow consistent terminology, no easy feat in an industry where most terms are ill-defined and many are overloaded. [There have been hours of discussions (i.e. arguments) on what, specifically, a single term means when used in ORA.] Additionally, meta-models (maturity model, SOA Service, functional breakdown levels, etc.) were created which all of the documents follow and incorporate as appropriate. (Arriving at agreement on the meta-models took weeks or months, depending on the topic.) In addition to terminology and meta-models, the perspectives provide a consistent set of architectural views ('view' as defined by IEEE 1471). However, there is little attempt to have each model (IEEE 1471) within the view follow a standard structure across perspectives. Instead, the goal of each model within the architectural view is to clearly illustrate the concepts being presented i.e. we have chosen clarity over contrived consistency.The ITSO Overview document describes the entire structure followed by ITSO.

This blog entry provides some "behind the scenes" commentary concerning the creation of the documents collectively known as IT Strategies from Oracle. There were three key concerns that the Oracle...

Do SOA and enterprise architecture now mean the same thing

  In a recent blog post, Joe McKendrick poses the question that I have been playing around with for a while regarding where and how SOA fits into EA.  He mentions that: Dave Linthicum predicted a couple of years back that SOA would be absorbed into EA. SOA is just good EA, he said. Do SOA and enterprise architecture now mean the same thing? | ZDNet I agree that SOA is good EA done at the Technology Architecture level, but is unique in that it has more and more relevance to the Business Architecture with each passing year (as oppose to decreasing in importance)   He also poses this great question: “Also, is it likely that all major technology expressions these days have elements of service orientation about them, so EA automatically = SOA on some level?” I agree, but might turn it around to be : SOA can be an automatic part of EA if it driven by the precepts that are derived from EA at higher levels of the architecture.  It is possible to use SOA technologies to simply do a “better” version of PTP integration.  And, in fact, there is some value in doing that, but it is not relevant to EA at that level of maturity.  I often talk about “Services” – with a capitol “S” – to distinguish them from “services.”  The difference being that Services have been vetted as being truly worthy at a Enterprise level.  That is where SOA appears on the EA radar; where SOA has the chance of positively impacting the organization’s agility, simplify IT, and drive costs down.  All of these things are the mantra of any EA effort.   Thoughts?

  In a recent blog post, Joe McKendrick poses the question that I have been playing around with for a while regarding where and how SOA fits into EA.  He mentions that: Dave Linthicum predicted a couple...

Application Architecture

Thoughts on John Zachman

I just perused Mr. Allega's (Gartner) recent article on the legal quagmire that is stirring around the Zachman brand, framework, and its two proponents. It is too bad such a pair of thought leaders will end their careers in such a manner. Upon reading the article I thought I would share some thoughts about Zachman.I had the privilege of taking their 5 day course on the topic of EA. It was the single key factor that expanded my thinking from Enterprise app/data/tech Architecture into true Enterprise Architecture. It drew me and my teammates at the time out of the food fight stage in our architectural maturity. Yes, you know the stage where you think all there is to architecture is picking the right technology? Zachman helped us crawl out of that primordial ooze. The 6x6 place mat with his framework sure looked cool on our cubicle walls. But it was something for practitioners, not stakeholders. It was a great way to classify all the information in an organization. But we all know that no one started a project to fill in all those cells. The framework got us to start systems thinking. He emphasized that enterprises - the companies you and I work in - are more complex than the Airbus 320 I've been schlepping across the country in. It takes an engineering mindset and discipline to get it all to work together correctly.Zachman is a unique guy. I kid you not, when I was working up the SOW for him to come teach his T&Cs require an old-school projector for his box of transparencies. Armed with his finger pointer he would talk using minimal breaths on the need for architecture. I saw him last speak at an SEI event in Pittsburgh. All I can say is I hope I have half that energy at his age.Allega provides good advice for any EA regardless of their framework:Keep a pragmatic focus on your EA efforts and don't get distracted by the rumblings, and posturings, of one framework proponent versus anotherRealize that any particular EA framework should provide a consistent organizing structure for enterprise architectural concepts and should not simply be followed as a rigid process or set of rules.Choose source frameworks quickly, recognizing which one is primary as an input to the development and categorization of your EA artifact and your EA program.Modify and enhance the framework, as required, to support your EA program.Do not attempt to follow a single framework rigidly. Its job is to provide a consistent organizing structure for enterprise architectural concepts, and it should be used pragmatically.Here at Oracle we have our framework which is derived from FEA and TOGAF. And as we use it we too use it a guide to structure our work. But it doesn't restrict our work either. At the end of the day no one hires EAs to execute a framework. Rather, EAs are hired to solve a concrete business problem. Frameworks are tools for the EA, not entrapments. Guys like Zachman and Locke are clearly thought leaders whose musings will continue to echo across cubicles and whiteboards for decades to come.

I just perused Mr. Allega's (Gartner) recent article on the legal quagmire that is stirring around the Zachman brand, framework, and its two proponents. It is too bad such a pair of thought leaders...

Application Architecture

Documenting Enterprise Architecture - IEEE 1471

Mike Walker has a nice blog post and links regarding the documentation of architecture. He talks about how the IEEE 1471 recommendation is being incorporated into an ISO standard with specific applications into enterprise architecture. I see this as a great step in advancing the craft of enterprise architecture. Related to my previous post on EA notation, the importance of clear EA documentation cannot be understated.From IEEE 1471 (and Documenting Software Architecture) I have consistently advocated for certain principles in documentation. The first is one diagram is insufficient to fully describe an architecture. One needs to produce multiple views based on their audience and specific business problem being addressed. The CxOs don't care about seeing the detailed SOA call trace over HTTP; they want to see OpEx reduction in their application portfolio. Second, a picture alone is insufficient. Now, when we're presenting to stakeholders we only show the picture (the view). But we should also include supplemental documentation with an "element catalog" that fully describes each box and line in the diagram. It goes a long way to making the document more valuable outside the presentation context.What techniques do you use to document your enterprise architecture? Do you follow (parts of?) IEEE 1471? Or do you have other approaches that you incorporate? I invite you to chime in here or over at Mike's blog post.

Mike Walker has a nice blog post and links regarding the documentation of architecture. He talks about how the IEEE 1471 recommendation is being incorporated into an ISO standard with specific...

Enterprise Architecture vs. Service Oriented Architecture

  I am in the middle of reading two books on EA, including the TOGAF 9 specification.  The other book, the one shown below, is proving to be an interesting and very useful read for anyone who wants to get some ideas about how to map EA and SOA.  I will do a full “book report” in a week or two when I am done. EA and SOA are, at this point, inextricably intertwined.  Rick correctly points out that SOA is the only software development approach that, when done correctly, links conceptual (and corresponding physical) artifacts directly to the business vision/strategy.  Thus, SOA is a linked subset architecture of the overarching Enterprise Architecture. It is a very well written book and the author, Rick Sweeney, makes some very good points. Here is the byline of his blog (SOA is the way Blog): This blog is dedicated to the promotion and advancement of the Service Oriented Architecture approach to business systems design. The purpose of the site is to provide a forum where people like myself who believe that SOA is the next baseline of the business application evolution can share and express ideas and help advance the institutionalization of SOA throughout the business domain. Welcome and thank you for helping to advance the cause. I am far enough in the book to recommend it, even though there are a few small things I would debate about.  None the less, for anyone who wants some information and viewpoints on how SOA and EA work together, this is a book to get.  I am actually reading it on my iPad from Kindle ;-)

  I am in the middle of reading two books on EA, including the TOGAF 9 specification.  The other book, the one shown below, is proving to be an interesting and very useful read for anyone who wants to...

EA Processes

What Notation for Enterprise Architecture Modeling?

I've been a huge fan of architecture modeling for over a decade now. I feel there is no better way to get stakeholders on the same page so quickly. It is true what they say...a picture is worth a thousand words (or meetings). I feel consistent notation is important for consistent interpretation of the "picture". For many years those implementing software-intensive systems have relied on UML to describe their code. I think the consistency and expressiveness of UML is a benefit to the developer but also the stakeholder in gaining understanding. One long-time colleague and friend had me going down the Google rat hole about 18 months ago. He comes from a DoD hard-core systems background. When I say system I mean they build the hardware, created the machine instructions and the the high-level compilers. When you need to blow stuff up, that is how you roll I suppose. Myself, I was corn-fed on COBOL and business systems whose only explosion was an abend or seg fault at 2:30 in the morning. However, both of us had something in common when it came to enterprise architecture; we needed a consistent way to express what was going on beyond all the silicon-based entities. Architecture description languages (ADLs) have existed in academia for sometime as well. But these seemed to be focused in the product space where "system" meant specialzed hardware or software (e.g., automobile, helicopter). I wanted something that was simple and extensible. And would cover the unit of architecture I was dealing with - the enterprise. Yes, the enterprise with its mix of people, process, and technology all (hopefully) aligned to meet corporate objectives. And I didn't think straight UML was the way to go.The nice thing about standards is there are so many to choose from. To date I've been exposed to a couple of modeling notations that would seem suitable for modeling enterprises. The first is ArchiMate that was ratified/certified by TOGAF not too long ago. The other is SysML. I've personally been using SysML for project work and for developing a reference architecture. Its expressive enough to be precise yet I've been successful in using it with non-IT stakeholders. Both modeling languages are derivatives of UML (technically, they are UML 2.0 profiles) so one benefits from any previous UML knowledge when manipulating diagrams.What sort of approach are you using to document current or future state enterprise architecture? Does a consistent, standardized notation even matter? I would love to hear your thoughts.

I've been a huge fan of architecture modeling for over a decade now. I feel there is no better way to get stakeholders on the same page so quickly. It is true what they say...a picture is worth...

Some of the Things EA’s Can Focus On

I was just thinking a bit about some of the tasks that an EA can “time slice” between to help ensure success.  So, this is just some thinking-out-loud thoughts I had: Make a list of contacts in your organization that you have not spent time with, but that could be helpful in the ongoing planning and implementation of your EA.  Then go visit with them and see if there are some areas to engage with them.  Get out of your normal interaction comfort box. Tally the guiding principles that you may have laid our and link each one to one or more success.  This can be considered as part of EA governance, but can also help test to see which principles have been fruitful. Make a list of some major themes, such as consolidation / virtualization / rationalization / service reuse and see if these are being applied and if they are successful.  If they are not being applied, find out why and if these approaches would better enable some key business strategies. Have you met with the implementation folks to check in and see how the technical roll out of the EA is proceeding?  Are there some lessons you can glean that can steer your understanding of an idealized EA vs. some of the practical realities? Have you read any good EA books lately?  I recommend Enterprise Architecture As Strategy, which is an important foundation for Oracles Enterprise Architecture Framework (OEAF). Enterprise Architecture As Strategy- Creating a Foundation for Business Execution   Anyway, those are just some thoughts I had.

I was just thinking a bit about some of the tasks that an EA can “time slice” between to help ensure success.  So, this is just some thinking-out-loud thoughts I had: Make a list of contacts in your...

(EA) Presentation Tips from Bolt | Peters

As EA’s, we use communication as one of our main tools.  I am always on the lookout for information and tips on how to present (in fact, how to *communicate* – bidirectionality is important).  So before you take one on the chin and are ‘bout to present your ideas, don’t get light headed and feint…go for a knock out! (ran out of ways to cram more boxing puns in there)  Check out this blog for some good pointers from bolt | peters.   Posted on June 23, 2010 I had the privilege of Jared Spool attending and critiquing some of my recent talks, and in preparation for a UIE webinar I’m giving, he took time to rip me apart give me some awesome feedback. His advice reminded me of notes I took almost ten years ago at an Edward Tufte seminar about giving great talks, and so the next logical step was to make old-timey boxing photos of them both and write a mashup of their talking tips. RIGHT? Both Jared Spool and Edward Tufte are known to be kick-ass speakers in the technology field – Tufte is all up in the freaking white house, and Jared speaks roughly 400 days a year around the world. I think we can learn a lot from their advice, and despite the artificial conflict introduced with boxing pictures, their tips are mostly complimentary. - by Nate Bolt Giving Great Talks: A Mashup » Bolt | Peters

As EA’s, we use communication as one of our main tools.  I am always on the lookout for information and tips on how to present (in fact, how to *communicate* – bidirectionality is important).  So...

Tools for Enterprise Architects: OmniGraffle for iPad?

Well, I have to admit to being a bit of an Apple fan and, of course, and early adopter of gadgets and technology in general.  So, when FedEx showed up with my iPad 3G last week, I was a kid in a candy store.  One of the apps that my “buy finger” was hovering over for a while (like all of 3 days) was Omnigraffle for the iPad.  I imagined that it would be very cool to use this with a customer’s EA’s to sketch out Business, Application, Information and Technology architectures.  Instead of using the blackboard, this seemed to offer promise as a white-boarding tool with obvious benefits over a traditional white-board.  I figured I’d get a VGA adapter, plug it into the customer’s projector and off we would go with a great JAD tool.  The touch pad approach offered an additional hands-on kind of feel. So, I made the $49.99 purchase + the $29.99 VGA adapter and tried to give it a go.  Well, I was both pleasantly and unpleasantly surprised.  It is both powerful and easy to use.  There are great stencils included for shapes, software icons, Visio shapes, and even UML notation.  There is even a free-hand tool that works well.  I created some diagrams pretty quickly.   The one below was just a test and took all of 10 minuets to do. The only problem was that Onmigraffle does not recognize the VGA output, so I was stopped dead in my tracks, as it were.  My use case was as a collaborative diagramming tool with other architects, though I can still use it off line.  I called Omnigraffle and they said that VGA support is on the feature request list so, hopefully, in a short amount of time, I can use the tool as I envisioned. NEW UPDATE: A question I got from Todd Biske “…was whether the touch interface has sufficient resolution. I've tried some basic sketching with Adobe Ideas, and I must admit, I find myself longing for a stylus. Can you comment on this?” So, the answer is yes.  You can use the 2-finger pinch motion to zoom in and out to well over 600%.  At that resolution you can make all kinds of intricate connections and refinements.  Hope that helps :-)     Review: Criteria Result Is it fun? Yes Is it Useful? Yes Does it Show Promise? Yes Did the VGA Output Work? No File/diagram Formats PDF, Onmigraffle proprietary, image   Quick Sample:       OmniGraffle for iPad - Products - The Omni Group

Well, I have to admit to being a bit of an Apple fan and, of course, and early adopter of gadgets and technology in general.  So, when FedEx showed up with my iPad 3G last week, I was a kid in a candy...

Enterprise Architecture IS (should not be) Arbitrary

I took a look at a blog entry today by Jordan Braunstein where he comments on another blog entry titled “Yes, “Enterprise Architecture is Relative BUT it is not Arbitrary.”  The blog makes some good points such as the following: Lock 10 architects in 10 separate rooms; provide them all an identical copy of the same business, technical, process, and system requirements; have them design an architecture under the same rules and perspectives; and I guarantee your result will be 10 different architectures of varying degrees. SOA Today: Enterprise Architecture IS Arbitrary Agreed, …to a degree….but less so if all 10 truly followed one of the widely accepted EA frameworks. My thinking is that EA frameworks all focus on getting the business goals/vision locked down first as the primary drivers for decisions made lower down the architecture stack.  Many people I talk to, know about frameworks such as TOGAF, FEA, etc. but seldom apply the tenants to the architecture at hand.  We all seem to want to get right into the Visio diagrams and boxes and arrows and connecting protocols and implementation details and lions and tigers and bears (Oh, my!) too early. If done properly the Business, Application and Information architectures are nailed down BEFORE any technological direction (SOA or otherwise) is set.  Those 3 layers and Governance (people and processes), IMHO, are layers that should not vary much as they have everything to do with understanding the business -- from which technological conclusions can later be drawn. I really like what he went on to say later in the post about the fact that architecture attempts to remove the amount of variance between the 10 different architect’s work.  That is the real heart of what EA is about; REMOVING THE ARBRITRARITY.

I took a look at a blog entry today by Jordan Braunstein where he comments on another blog entry titled “Yes, “Enterprise Architecture is Relative BUT it is not Arbitrary.”  The blog makes some good...

Where is the value of OEA

In a room full of architects, if you were to ask for the definition of enterprise architecture, or the importance thereof,  you are likely to get a number of varying view points ranging from,  a complete analysis of the digital assets of an organization,  to, a strategic alignment of business goals/objectives to IT initiatives.  Similiarily in a room full of senior business executives,  if you asked them how they see their IT groups and their effectiveness to align to business strategy,  you would get a myriad of responses,  ranging from, “a huge drain on our bottom line”, “always more expensive than budgeted”, “lack of agility,  by the time IT is ready,  my business strategy has changed”, and on the rare occurrence, “ a leader of innovation,  that is lock step with my business strategy”. However does this necessarily demonstrate the overall value of enterprise architecture.  Having a framework, and process is of critical importance to help produce a number of the artefacts that ultimately align technology goals and initiatives to business strategy,  however,  is that really where the value is?  I believe that first we need to understand the concept of value.  Value typically is a measure of sorts,  when we purchase a product it’s value is equivalent to the maximum amount that someone is willing to pay for the product,  however,  is the same equation valid in terms of the business value of enterprise architecture? Is the library of artefacts generated through a process/framework, inclusive of a strategic roadmap to realize the enterprise architecture where the value is? If we agree that enterprise architecture is the alignment of IT and IT assets to support business strategy, and by achieving our business strategy, we have we have increased the business value of the enterprise then;  it seems that, in order to really identify the true value of an enterprise architecture,  we need to understand how we measure business value .  A number of formal measurement methodologies exist for this purpose, business models, balanced scorecards, etc   After we have an understanding on how to measure the business value of each of the organizational units within an enterprise, then we understand how the enterprise architecture contributes to the success of business strategy,  and EXECUTE on the roadmap to implement, and deliver the IT initiatives that provide MEASUREABLE returns, As we analyse the value chain of each of the individual organizational units within the enterprise we may identify how that unit has performed by quantitatively measuring it proximity to achieving the goals defined by the business for each unit. However, It would appear that true business value (the aggregate of all of the business units in the value chain), is to some degree subjectively measured  as for public companies this lies in shareholder value,  as the true value, or be it, the maximum amount that someone would pay for shares of an organization.

In a room full of architects, if you were to ask for the definition of enterprise architecture, or the importance thereof,  you are likely to get a number of varying view points ranging from,  a...

Growing Into Enterprise Architecture

I am writing this post as I am in an Enterprise Architecture class, specifically on the Oracle Enterprise Architecture Framework (OEAF).  I have been a long believer that SOA’s key strength is that it is the first IT approach that blends or unifies business and technology.  That is a common view and is certainly valid but is not completely true (or at least accurate).  As my personal view of EA is growing, I realize more than ever that doing EA is FAR MORE than creating a reference architecture, creating a physical architecture or picking a technology to standardize on.  Those are parts of the puzzle but not the whole puzzle by any stretch. I am now a firm believer that the various EA frameworks out there provide the rigor and structure required to allow the bridging of business strategy / vision to IT strategy / vision. The flow goes something like this: Business Strategy –> Business / Application / Information / Technology Architecture –> SOA Reference Architecture –> SOA Functional Architecture.  Governance is imbued throughout to help map, measure and verify the business-to-IT coherence. With those in place, then (and only then) can SOA fulfill it’s potential to be more that an integration strategy, more than a reuse strategy; but also a foundation for tying the results of IT to business vision. Fortunately, EA is a an ongoing process that it is never too late to get started with an understanding of frameworks such as TOGAF, FEA, or OEAF.  Also, EA is never ending in that it always needs to be applied and re-applied, even once a full-blown Enterprise Architecture is established -- it needs to be constantly evolved.  For those who are getting deeper into EA as a discipline, there is plenty runway to grow as your company/customer begins to look more seriously at EA. I will close with a pointer to a Great Book I have recently read on this subject: Enterprise Architecture as Strategy (http://www.amazon.com/Enterprise-Architecture-Strategy-Foundation-Execution/dp/1591398398/ref=sr_1_1?ie=UTF8&s=books&qid=1268842865&sr=1-1)

I am writing this post as I am in an Enterprise Architecture class, specifically on the Oracle Enterprise Architecture Framework (OEAF).  I have been a long believer that SOA’s key strength is that it...

Enterprise Architect or Enterprising Architect: Will the Cloud disrupt traditional paradigms of EA? (Part 1.)

Enterprise Architecture is all about tapping synergiesacross the enterprise - in a structured and consistent manner. Goes withoutsaying that different forms and flavors of EA exist dependent upon the startingpoint, organizational culture or operating model. Forrester characterizes EAbased on the dimensions of orientation (Business or Technology) and focus(Project or Strategy)  [see: Characterizing EA Teams and their challenges.] But there is one thing in commonacross all types of EA, and that is - having a shared enterprise-wideunderstanding of what needs to be done for the larger good of the company - andhave different parts of the enterprise converge towards that vision and architecture.   And the mechanisms EA has traditionally used to driveconsistency and shared values are - reference architectures, standards (for products, tools, canonicalmodels etc.), architecture principles and so on, which are adhered to by theimplementation projects and enforced at multiple levels using governanceprocesses and gating techniques.   So why is the Cloud paradigm such a big deal? Well forstarters, it threatens the whole premise of IT sourcing and decision making - wherebusinesses, at least theoretically, can now bypass corporate IT shopscompletely to source their applications, infrastructure and platforms fromexternal providers - in a cost-effective on-demand basis.   On a less dramatic level, it shifts the focus from choosingand deciding about products or architectures to instead being concerned aboutservices - regardless of the underlying products or tools enabling the services- and without having to worry about managing or maintaining those services(unlike in the case of say SOA). But it doesn't stop there - it also introducesinteresting twists to key EA processes.   For example, zooming in on one process - the classic SoftwareDevelopment Life Cycle (SDLC), some of the nuances that could get introduced atvarious stages of the process with the Cloud option are:   -         Genesis: Traditionally, the EA team wouldcollaborate with the business to understand and scope the needs - and align itwith the enterprise architecture (bringing to bear the existing technologicalcapabilities that can satisfy those needs thereby promoting sharing or reuse orbuilding new ones if needed). However, given its  relatively low barrier to entry, in thescenarios where the Business is not sure of the viability of their proposal,they can go straight to the Cloud instead to "experiment a bit" before solidifyingtheir requirements - which could be a path of no return..   -         Approval: Instead of now having to providestandardized ROI or cost-benefit analysis justifying the products that need tobe bought or charge-backs that need to be agreed upon upfront for shared assets,the Business can provide operational expenditure outlines and go out to theCloud to source their requirements. No CapEx sticker shock, no new productintroduction training line item expenditures, no gnarly charge-back agreementsbetween Business Units - in short, no need to conform to existingenterprise-wide Reference Architectures to meet individual project needs.   -         Development & Deployment: The development anddeployment teams would now be sourcing from and conforming to the Cloud API andservices - without the EA team becoming a cop enforcing the referencearchitectures or corporate standards at various checkpoints. With overarching cross-projectoversight not relevant anymore, each project would tend to work in its own Clouddevelopment sandbox - party engendered by the partitioning paradigm of theCloud itself..   -         Operations & Maintenance: Barring someexceptions, traditionally the EA teams have not been hugely relevant to the Opsside of the house - but with the Cloud, even that seems to be waning. The Cloudproviders will furnish the relevant tools for management and reporting - and takeaway the onerous tasks of patch management version upgrades, HA/DR and thelike. What value will the EA add here?   Given that the entire notion of enterprise architecture isbased on the premise that the whole is greater than the sum of its parts, andthat there are far greater cost or agility or innovation options when thearchitecture is optimized for the enterprise as opposed to optimized for apoint solution or a business segment, it appears that the Cloud paradigm isparadoxical to enterprise architecture.   With each Business Unit inexorably being pulled to its own"point" Cloud, will EA go from dealing with Business silos to managing Cloudsilos? Or is the Cloud going to marginalize Enterprise Architecture? How canthe traditional EA become more enterprising to embrace the Cloud and evolveit's processes and models to prevent fragmentation and segregations of Cloudsourcing solutions?   Would like to hearyour thoughts and explore the options in the next posts.

Enterprise Architecture is all about tapping synergies across the enterprise - in a structured and consistent manner. Goes withoutsaying that different forms and flavors of EA exist dependent upon the...

The Process Centric vs. Information Centric approach to SOA

  In his well articulated article, Johan den Haan talks about the merits of choosing an Information Centric approach to your SOA over a Process Centric one.   He writes: An alternative for the previously presented process centric approach to SOA is, what I like to call, the information centric approach to SOA. This approach attempts to solve some of the problems of the process centric approach. Instead of supporting business processes by defining service orchestrations as fixed flows, the information centric approach supports business processes by defining activities with pre and post conditions. Simply said: each activity in a business process is represented by an implementation of that activity and a pre and post condition for this implementation. The Process Centric vs. Information Centric approach to SOA My thinking is that both centricities are good and valid in certain cases.  The traditional ESB/BPEL service/orchestration model is useful in many cases where, for example, and order needs to be taken in, validated, and sent the the various back-end systems that handle the request.  Some of these calls are fire and forget by the fact that these systems are often autonomous and without full SOA API’s.  The BPEL process can manage the various fire-and-forget as synchronous calls with numerous approaches (polling, response queues, etc…). My take on the Info centric approach is that it strives to make each operation ultra self sufficient because the services need to be built to handle pre and post conditions.  I worry that this approach takes the idea of atomic operations to a whole new level and risks death by over engineering. Where I do see value is making sure that you have a canonical model for managing and normalizing the shape of the data as it passes through the SOA layer.  Also each atomic service can and should have the appropriate CRUD operations on it.  The service should not have the logic in it to know what to do if a failure is met, but should report that error to the orchestration layer so it can decide what to do.  This is important because the “what to do” can be very context-driven based on who or what is calling that service.   Just my thoughts (at this moment) on the subject.

  In his well articulated article, Johan den Haan talks about the merits of choosing an Information Centric approach to your SOA over a Process Centric one.   He writes: An alternative for the...

Oracle’s Enterprise Solutions Group, Oracle US

 The past few weeks I have been helping to grow our North American Enterprise Solutions Group here at Oracle and it has been both exciting and challenging.  The Enterprise Solutions Group, Enterprise Architecture team is chartered with leading the Enterprise Architecture Program for North America Sales and Consulting.  They provide North American Sales Consulting with experienced enterprise architects and strategists to drive growth of enterprise solutions sales. Members of our Enterprise Architecture team are the best and the brightest.  Our Enterprise Architects are high-level, seasoned professionals with experience in many industry verticals including, but not limited to, information technology, covering industry verticals of automotive, banking, securities, finance, manufacturing, government, chemical, agriculture, higher education, and healthcare.These types of professionals are unique and very rare in the industry and I was quick to realize that finding this kind of rare talent with the “right stuff” would prove to be quite a challenging task.An Enterprise Architect in the Enterprise Solutions Group at Oracle has a variety of roles. They are pre-sales consultants, working with clients and sales people to identify ways that the company can provide support to large scale clients who are looking at making significant investments in Oracle technologies and to assist with transforming their business. The Enterprise Architect supports the sale and then continues into a post-sale capacity supporting the client.In a post-sale role, these Enterprise Architects provide coaching and guidance to clients who will be executing the Oracle Architecture Development Process (OADP). They work intensely with them to create the initial deliverables and a roadmap for use in executing their business and IT strategies. Then, over time, they engage at periodic checkpoints to provide an external review of the execution. The Enterprise Architects may also be engaged in executing specific services such as Application Portfolio Rationalization, IT Consolidation, or Business Process Optimization. When our Enterprise Architects are not engaged with clients, they develop tools and processes for use by the organization. These areas include developing and delivering enablement training, enhancing Oracle models and tools, and providing support to our certifications processes. The Enterprise Architects also expand their knowledge with internal and external training.Our Enterprise Architects consult with senior industry leaders, becoming their trusted advisors and developing business-driven strategies and leading the delivery of complex solutions that allow those strategies to be realized. We are currently hiring highly qualified, seasoned Enterprise Architects to join our Enterprise Solutions Group.  Candidates can be located anywhere US Nationwide, as long as they can travel.  If you would like to be considered for one of these prestigious career opportunities, please send word document version of resume with full contact details, saved backwards compatible, to mc.didone@oracle.comThis article was written by MC Didone (Senior Recruiter) and Ross Emerton (Director, Enterprise Architect)

The past few weeks I have been helping to grow our North American Enterprise Solutions Group here at Oracle and it has been both exciting and challenging.  The Enterprise Solutions Group, Enterprise...

Oracle Application Server Strategy

In yesterday’s conference on the Oracle/Sun merger (which was very informative and well done IMHO), the strategy around the middleware / tools space was laid out.  There are a series of web casts ALREADY available on the subject (see below).  I thought I’d point them out for any followers who are interested in the direction of things.  It is notable how prevalent GlassFish will be featured in the product bundles (not hidden away in a dark room to be forgotten as some people thought it would be). Sun offerings including the Sun GlassFish Enterprise Server, Sun Java System Web Server, Sun Java System Web Proxy Server, and Java HotSpot Virtual Machine complement and extend the existing product line-up to increase the breadth and depth of Oracle's foundational middleware software. In summary, the combination of Oracle's application server technologies and Sun means: GlassFish continues as the Java EE reference implementation GlassFish Server included in every Oracle WebLogic Server offering Sun Java System Web Server part of new Oracle Web Tier offering For more information: Watch the application server strategy webcast Explore Oracle's middleware strategy in this series of webcasts Learn more about the role of Sun middleware products in Oracle's middleware strategy Visit Sun.com for details on Sun's products Oracle WebLogic Products | Oracle

In yesterday’s conference on the Oracle/Sun merger (which was very informative and well done IMHO), the strategy around the middleware / tools space was laid out.  There are a series of web casts...

Rethinking Information Architecture for the New World (Part 4)

In the last three parts of this blogging series, we discussed the fundamental impetus behind redoing the information architecture in these fundamentally changing times. New economics, technologies, user behaviors, user expectations and business climates having set the requirement for making information more available, more accessible, more malleable, more business-ready and more secure against the threats of privacy breaches. As a mechanism for making that transformation, we discussed the following 3 steps: 1. Establish a common language for conversations between business and information technologists (an EA framework usually calls this the business architecture) 2. Define a shared set of principles around how information is treated and leveraged by the business 3. A governance model for course correction when strategies and tactics are not working and need to be rethought. The last blog post (part 3) discussed item 1. In this post, we will take on number 2. However, before I do, wanted to bring up a question I received in an email about these three steps - “where is the implementation step in these three?”. Great question. My answer was and is “implementation happens everywhere else :-)”. What I mean by that tongue and cheek remark is that once these three are addressed, all we do is implement. Once we have a common language of our enterprise information, a set of guiding architectural principles for our implementations and a set of processes and measures to ensure we are meeting our target information architecture (i.e. implementation governance), all we need to do is execute the actual implementation plan(s). This mindset is not something I have come up with, but is the fundamental philosophy of a practical enterprise architecture process. Now to return to the discussion of this post – information architecture principles. Let me first list the top “data principles” that TOGAF 9 lists on its website: Data is an Asset Data is Shared Data is Accessible Data Trustee Common Vocabulary and Data Definitions Data Security When you read these principles, you can often have what I call a “duh” moment. Who would disagree with “Data is as Asset”? Same for most of the others. “Data Security”, seriously? I am not a big fan of these principles as they stand. However, I think these provide a great foundation for more specific and more enforceable principles in specific solution architectures. For example, a better principle than either “Data is an Asset” and “Data is Shared” is one such as “Data is an Asset that is Shared across all Lines of Business”. Even better is one that can be more prescriptive like “All Corporate Customer Data is an Asset that is Shared across all Lines of Business”. Imagine your CTO or CIO sets that as a general architecture principles for your IT organization. How do you think that would affect your design and implementation decisions when you are implementing the next CRM system for a specific Line of Business? Does it matter that the information is stored in an Oracle database, a file system, a DB2 system or as raw binary files? At that point, the implementation technology is less important. More important is that the architecture supports sharing that data. Each architecture principle should not be a simple statement. While the statement is useful for communication purposes, it needs to be backed up by a rationale and a set of implications so that the entire organization, who is being targeted, understands how their day-to-day decisions should be influenced by the principle. Refer to TOGAF’s overview on architecture principles to get a more substantive overview. Understanding and fully internalizing the notion of architecture principles can take a little time but once you are there, you will appreciate its quiet power. Please comment if you are interested in a more examples and applications of information principles.

In the last three parts of this blogging series, we discussed the fundamental impetus behind redoing the information architecture in these fundamentally changing times. New economics,...

Discussion: The Enterprise Architecture Network | LinkedIn (Enterprise Architecture at Oracle)

In a response to my blog post, Bhushan poses an interesting point in the comment.  Posted on December 22, 2009 00:23 Bhushan Kodibagkar: What is your Enterprise Architecture ? What should be your Enterprise Architecture ? Are we saying that the broad term of Enterprise Architecture comprise of processes that help organizations get from point A to point B ? Then should CIOs and CTOs be expect EA professionals. It sounds like we are saying EA is everything under the enterprise technology domain and the strategic business management domain as well while we are at it. Discussion: The Enterprise Architecture Network | LinkedIn (Enterprise Architecture at Oracle) My take on the point made is: How far reaching is the EA role expected to be?  Is he/she expected to be all things to all people?  That is a pretty tall order. I did a search of the web and found this *sample* job description which is interesting: http://www.mariosalexandrou.com/free-job-descriptions/enterprise-architect.asp I won’t restate the description, but they define the role as “Qualified enterprise architects are a rare breed as they must understand a company's business while still being able to delve into nitty-gritty technology issues.”  It is also pretty interesting that, as I have said before, communication skills are key. Anyone have any more thoughts?

In a response to my blog post, Bhushan poses an interesting point in the comment.  Posted on December 22, 2009 00:23 Bhushan Kodibagkar: What is your Enterprise Architecture ? What should be...

Database Consolidation - Oracle as a Service (OaaS)

Over the last few years my team has helped a number of key and strategic customers with how organisations with widely deploy stand-alone Oracle database environments find a more cost effective and efficient solution for the delivery of database services.  More and more we see each corporate initiative or project acquires its own hardware & software and establishes separate hosting & support arrangements. Consequently, there has been (and will continue to be) a proliferation of servers and software that all fundamentally do the same thing - provide Oracle database services for applications to consume. A more effective and cheaper way of providing Database Services is to "pool" several independent database servers together and produce an Oracle as a Service (OaaS) grid.  In this architecture, applications would connect to a single shareable instance of Oracle as they would any other Oracle instance. The business applications would be isolated from each other and explicit portions of Oracle processing power allocated to each one - a high-use application would be granted a large portion of processing power, a low-use application would be granted less. This provides Oracle customers with a number of realisable benefits: Higher availability; as all participating applications immediately benefit from automatic failover infrastructure. Cost savings; significant capacity for savings on hardware through better hardware utilisation and the use of cheaper commodity servers. Better service through centralised management; organisations can benefit from higher quality by leveraging a central team of database administrators. Reduced risk; the entire environment is managed, support is centralised and process, procedure and skills are standardised. OaaS Design Pattern The OaaS design pattern has been applied at a number of strategic customers that have delivered significant business benefit and is typically deployed as follows: Construction of one, or more, clusters consisting of standardised commodity hardware components that hosts these shareable Oracle instance Establishment of procedures for project & application support teams to engage with the Oracle shared services team and have their database applications hosted in this environment Definition of a cost, funding & operational model for the shared Oracle environment and the organisations IT operations team. Reasons to consider Consolidation In the current economic climate, keeping recurring operational costs down is imperative. Consolidation will assist the reduction of total cost of ownership (TCO) in several ways, including envisaged savings in hardware, software and hosting, as follows: Reduced administration. By standardising and reducing the number of servers, businesses reduce the complexity of the infrastructure they must administer. Fewer support staff can therefore manage the same service demands. This standardisation also facilitates the provision of 24/7 support using worldwide support resources. Reduced operational costs. Increase in service capacity and growth are achieved with better utilisation of resources. Typically, fewer servers are required, resulting in hardware and power savings. Reduced data centre costs. Site space formerly used for IT services can be returned to the business, and existing facilities can be used more efficiently. Reduced data centre hosting costs. Typically, hosting contracts are based on infrastructure under management - the less the infrastructure under management, the less the cost. Reduced revenue loss through higher uptime/availability. Consolidation reduces the cost of implementing high-availability solutions, which reduces revenue losses due to downtime. Improved service management. By standardising and reducing the complexity of service infrastructure, organisations facilitate more effective service management processes, tools, and automated system administration. Simplified contingency planning solutions. A simpler service infrastructure means that more services can be restored when a site failure occurs. Improved quality of service (QoS). Consolidation will facilitate improvement in application up-time and will deliver higher systems performance. Increased reliability and availability. Server consolidation makes it more economic to provide high-availability configurations and dedicated support staff. Organisations also benefit from implementing better storage management and service continuity solutions. Improved performance. Standardised systems deliver more predictable performance, and proprietary technologies such as data compression can improve query response times. Improved infrastructure agility. In uncertain times, flexibility and the ability to respond quickly to changing needs of the business can help to maintain the competitive edge. Consolidation results in a more standardised, centralised and dynamic infrastructure, which makes it possible for systems to be more responsive to change and to quickly adapt to business needs. Improved consistency. Consolidation improves interoperability, and makes systems more productive and easier to manage: Better integration. A consolidated platform provides for easier, and cheaper, systems integration, which improves data consistency and reduces the complexity of tasks such as extract, transform, and load (ETL) operations. Centralised management. Because consolidation facilitates centralised management, it becomes easier to implement standard policies across your systems. Reduced carbon footprint. With greater emphasis on sustainability, many organisations are striving to reduce the environmental impact that their activities have. Consolidation enables organisations to reduce their energy consumption by using less hardware as well as by using that hardware more efficiently. Improved resource utilisation. Most applications that utilise Oracle elect to provision a server/s with capacity that will exceed their maximum peak load. It is a global phenomenon that many database servers run at low utilisation rates. In a consolidated deployment model, idle capacity across this infrastructure can be reclaimed by reducing the total number of required servers while not affecting application performance or availability (although the extent of the envisaged savings need confirmation within each particular organisations environment). OaaS – The way forward Traditionally the type of application workload for the database was a key consideration in designing and configuring the environment as allocations for, and use of, resources can be very different depending on whether the workload type is Online Transaction Processing (OLTP) or Decision Support System (DSS).  In October 2008, Oracle unveiled the Oracle Exadata family of products which simplifies the deployment of an OaaS platform.  The Exadata family of appliances are geared towards providing high-performance, ready to scale database processing capabilities specifically mixed applications workload (DSS or OLTP) and simplifies the first step in the Design Pattern, by providing a pre-configured standardised platform.

Over the last few years my team has helped a number of key and strategic customers with how organisations with widely deploy stand-alone Oracle database environments find a more cost effective and...

EA Bashing?!? Open Season on EA’s??? Who is at Fault? (Or should the question be how do we fix it?)

There are a number of blogs and posts out there that are centered around the validity (and even the value) of having Enterprise Architects at all.  In a recent ebizQ Forum posting by Neil Ward-Dalton, the question is opened up for responses of which there a number of good and worthy responses (see link below).  I want to state that I have meet with a number of EA’s who “get it” and do add value.  So I, for one, say ENOUGH already.  EA’s perform a valuable function that would otherwise be left to chance (hardly an engineering construct in anyone's view). True, EA’s are constrained by the reporting structure as mentioned in the posts.  Also mentioned are the shortcomings of frameworks as well as the very definition of what an EA really is.  Those are all valid points as well.  Yet some people are able to cut through these concerns and actually add value. I will add another issue to the fire, which is time.  I have seen so many projects recently where everyone gets the value of doing it right (deep integration of the EA with Business Units, using SOA, Governance, Virtualization, etc..) but these notions are the first to get killed as pressure mounts.  A lot of people I meet want to get it right and have enough “personal power” to overcome the shortcomings posed by a less than optimal environment. Some issues EA’s face Reporting structure/sponsorship Frameworks (or lack there of) Definition and scope of EA Focus of EA’s being constantly down-leveled info nitty-gritty issues (counting CPU’s for a project) How do you measure EA success? How do you communicate EA success? (see http://blogs.oracle.com/enterprisearchitecture/2009/10/archbeat_ea_visibility.html for a podcast on this topic) Time All of these things can be solved - as there are solutions for each of them.  For example, the Oracle Enterprise Framework solves the problem some other frameworks have of being too rigorous - to the point of making them too confining to actually “get work done.” The Oracle framework takes a big picture view but also focuses on delivering value, not run-on-forever-science-experiments.  (See: http://www.oracle.com/technology/architect/entarch/pdf/oea_framework.pdf).  It is my belief that this framework is rigorous enough to be valid, but flexible enough to be practical. So, who is at fault?  The EA’s who are honestly trying to maintain the big picture view by mapping business strategy and trends to technology enablement and working to overcome shortcomings like the ones mentioned here (and often successfully)?  No.  Should the question, instead, be - How do we fix all this?  That is the question I’d like to pose.  Not “Is EA Dead,” but rather ideas for refining the role (and even profession) so that it better matches the needs of today’s businesses (which themselves are always changing).  If EA’s are not there to help pull everything together, who will???  Someone needs to!  Otherwise it will be right back to “every LOB for themselves.” The role / function of EA will remain ever increasingly valuable as the nexus for pulling together business and IT across Line of Business (LOB) boundaries, no matter what you call the actual role (can you imagine a new title such as Business Technology Vision Synergist???) What should we do differently where we do have poser to change things?  Ideas anyone???? Neil Ward-Dutton: The original vision of Enterprise Architecture (as proposed by Zachman and others) was that it was about understanding an entire enterprise as a system - that is, understanding the connections between the structure of the business, its capabilities, its organization, and so on (as well as the structure of the IT systems which supported the enterprise). Do today's EA practitioners get at all close to this vision in terms of their influence and understanding, or are they really Enterprise IT Architects - only concerned with IT systems, even if at a large scale? Do Today's Enterprise Architecture Practitioners Get at all Close to the Original Vision of EA? - ebizQ Forum

There are a number of blogs and posts out there that are centered around the validity (and even the value) of having Enterprise Architects at all.  In a recent ebizQ Forum posting by Neil Ward-Dalton,...

Rethinking Information Architecture for the New World (Part 3)

First of all, I am very happy to return back from my very intense month of October on the road for work and mini vacation at the end of it all in the great city of London. And now happier to be able to resume blogging on my favorite topic of information architecture. To get back to my traveling for a minute,  I picked up the latest Harvard Business Review at Washington Dulles while I was waiting for one of my flights going somewhere at some point in October (its all a bit blurry now). Last month’s HBR had an IBM advertisement that I felt was insanely wise and sums up exactly what I have been meaning to convey all this time on the subject of information architecture. Except, they were able to say it in the following 15 words: “Your data is trying to tell you something.  Is your business built to hear it?” I have to hand it to IBM for their ability to make a pitch-perfect pitch on information architecture. Whether they have anything of value to sell on that topic is another discussion, but at least they have the marketing down. Ok, so enough about marketing and advertising. Let’s return to where we left off our discussion in part 2 of this blog series. To recap, we discussed that there are fundamentally three things an architect, dealing with modernizing their enterprise information architecture, has to define to make a successful transformation in how they leverage information in the new world: 1. Establish a common language for conversations between business and information technologists (an EA framework usually calls this the business architecture) 2. Define a shared set of principles around how information is treated and leveraged by the business 3. A governance model for course correction when strategies and tactics are not working and need to be rethought. Let’s take them one at a time. 1. A Common Information Language This is probably the most challenging aspect of information architecting. And especially, given we are almost always starting with a legacy environment where systems have many, often inconsistent, data models, rationalizing all the data, their semantic and their physical structures is where we tend to spend overwhelming amounts of time and, usually, resort to frustration and eventually giving up that mind-numbing endeavor. Here’s a very simplified example of lacking a lacking language of information: Here are two data model records from two applications: System A System B Product: Name, Price, LOB, Manufactured At Product: Name, Price, Purchased By, Manufactured At   Can you guess which one is a product that the business is selling and which one is a product that the business is buying from suppliers? If you can, there is a 50% shot you are not right. This is precisely the challenge of normalizing data definitions and models to a common semantic that all parties, relevant to producing or consuming this data, is able to easily understand and leverage this information for their purposes. While this exercise can involve solutions such as master data management, data integration, data analytics, data cleansing, etc, at the heart of it, it is about making data accessible (a key principle in data architecture). Now, you might be wondering what is a practical and low-risk way to normalizing all the data in your enterprise so you can achieve this normalized information language. In my experience, I would recommend key high-level steps to practical information semantic normalization: a. Select a Business Process or Function – Taking a business process lets you work with a small set of data that is consumed by a business process. This is very critical to making the enterprise data modeling process a low risk proposition for all stakeholders. You don’t want to be touching and messing around with too many moving parts since that might take too long and complicated to normalize. b. Ignore the current data models – Define a logical data model that doesn’t dwell on the specific physical characteristics of the data model (e.g. data type, naming conventions, etc). Instead defining a clean and simple model that makes sense to a business user executing the process is a decent validation of the desired data model for architecture. c. Map your Logical Enterprise Data Model to Specific Systems – If you are working with a specific business process, your next task is to map those logical objects you have modeled in step b, to the actual data models in the different systems that are touching the business process. This approach takes a just-enough mindset to information modeling and you are normalizing only the systems that are critical to process execution. d. Rinse and Repeat across other business processes This approach to information semantic normalization and building out a canonical data model for your enterprise is often supported using MDM solutions. However, it is important to keep in mind that having an MDM system doesn’t automatically buy you a master data model. You can certainly use industry standards and reference models, however at the end of the day someone has to go through this exercise to create a data model that houses your enterprise’s strategies and functions. At the end of the day, your enterprise data model might look something like this at the 10,000 feet level. What comes after this is what makes your business different from the competition. In the next post of this blog series, we will discuss the architecture principles (and the rationale behind those principles) to govern and influence the decisions you need to make around building out the information architecture. Happy friday to you all.

First of all, I am very happy to return back from my very intense month of October on the road for work and mini vacation at the end of it all in the great city of London. And now happier to be able...

Riding the “Enterprise Information Bus”

27th October 2009 heralded the start of the EA Roundtable series in the UK with the first discussion focused on

27th October 2009 heralded the start of the EA Roundtable series in the UK with the first discussion focused on Managing" the Information Explosion Challenge. The customer group comprised of Enterprise Architects from a diverse range of industries ranging from Transportation and Public Sector to Financial Services  assembled at  Bafta’s prestigious Headquarters in London. There are many ways in which this Information Architecture focused topic could be interpreted (see related blog on this subject by Hamza Jahangir) ranging from the management of ever increasing data volumes (e.g. a key factor underpinning many new industry initiatives such as Smart Metering or simply the proliferation of business/social collaboration) to an integration/search perspective where careful consideration is required around how you bring all related forms of information together (structured/statistical or unstructured/semantic) to make it more useful and meaningful to the information consumer. Our discussion focused more on the latter than the former but also in the context of: The changing nature of business operating models and growing decentralization of data sources The challenges associated with governing unstructured data sources whilst still trying to apply the same architectural principles as you would expect with structured data The criticality of unstructured data to core business process within an organization Whilst it was generally accepted that there was an equal explosion of structured and unstructured data, the debate focused on the fact that businesses seldom make best use of unstructured data outside of the context of major business applications (e.g. ERP or CRM). This is largely due to unstructured data being more subject to interpretation and that without some form of role-based semantic filtration, its true value/potential may never be realized. Moreover, the semantic nature of unstructured data makes it more difficult to govern compared to its structured counterpart thus questioning its intrinsic value and provenance – put simply, can businesses trust the data ? A mash up is typically associated with the fast/simplified integration of information from multiple data sources. However, they are often hand-crafted in terms of binding structured and unstructured data sources for a specific purpose or information consumer role rather than being dynamically generated based on a query based (ad-hoc) interpretation. To that extent, not all information (stored in a diverse range of formats – e.g. Video, Blogs, structured database tables) may be included within a given query even though all this information could be semantically linked. Are we therefore truly harvesting the value of the Information Explosion ? Despite all of these issues, the group agreed that it would be useful for MIS systems to query/search both structured and unstructured data sources to enrich the value of corporate MI. The concept of the “Enterprise Information Bus” was discussed as a data services driven mechanism (enabled via Service Oriented Architectures) for provisioning both traditional statistical data sources (e.g. packaged application schemas or data warehouses) as well as semantic data structures . The complexity of binding the data sources would be abstracted from the information consumer who would merely see the bus as a dynamic information provisioning device. Furthermore data could be dynamically pushed onto the bus as well as pulled but the logic of semantic association would again be abstracted from the information provider. Finally, the idea of a '”Semantic Repository” was also put forward as a method of adding semantic structure to unstructured data sources that would help the Enterprise Information Bus to associate the information with structured data. Cool stuff eh ?! Finally, the group also debated the issue of data sources being distributed across multiple infrastructures (i.e. some on customer premise, others hosted within public or hybrid clouds) as a by-product of the Information Explosion and the knock on impact  of being able to efficiently collate/provision this data whilst maintaining the business and architectural principles of integrity/trust and security etc… which is a great lead into our next EA Roundtable topic on Cloud" Computing on 18th November 2009 …

EA is not dead … Long live the EA

In his latest blog post - Is Enterprise Architecture dead - Richard Veryard argues the demise of the role of EA stating: "I can't see much recognition or respect for the value of "Enterprise Architecture" except among the ranks of EA practitioners. In many organizations, the function of enterprise architecture is squeezed or marginalized, if not rejected altogether." A related blog post from David Sprott on The Death of Enterprise Architecture also suggests that EA's are less than successful and the profession is in a state of decline. To be honest, its not the first time I've heard these arguments, both in terms of the role as well as the function. There seems to be more discussion on the pitfalls of EA today (see related Gartner article blog post) as opposed to the benefits EA can bring. Is the fundamental issue that the value/scope of the role/practice is simply misunderstood by both business and IT and that organizations are simply hiring the wrong people into the role ? Do EA's have the right sponsors within their organizations ? Lets start with the Profession. A subsequent post by Veryard on the EA Profession states that it suffers from associations with Professional Organizations (e.g. The Open Group) that have relatively few members and that have fundamentally failed to communicate the business value of architecture to the industry at large. Furthermore their certification methods/criteria are based on theory/one-time examination rather than real world practice and little is done in the way of maintaining quality assurance and governing against maverick or incompetent practitioners. Whilst I have to agree with these sentiments, I don't agree that you can judge a profession on the basis of its associations or governance structure. Professional bodies such as the Open Group are formed to provide guidance, operating frameworks, methodologies and principles. Organizations looking to implement the profession often use these as professional blocks rather than, for example, implementing the entire TOGAF methodology and framework. Furthermore, large multi-nationals such as HSBC are firmly committed to professional bodies such as the Open Group (all their Solution/Enterprise Architects have been or are in the process of obtaining TOGAF 9 certification) and additionally most of my customers are asking for an Oracle mapping to TOGAF. This of course does not prove that there isn't an issue with the EA role or profession. I have read other Blogs that argue that the role is required but its the EA reporting line that is the real issue - i.e. the EA role should report into the COO as opposed to the CIO as it provides the relevant level of business/IT neutrality to the role whereas typically the EA reports into CIO/CTO where the business may perceive the architect to be more IT than Business focused. Moreover, it's rare I consistently meet the same type of EA. They come from a range of backgrounds ranging from business to IT and they are all in different stages of maturity in terms of their practice of EA. And here we get to the fundamental issue, whilst EA is not a new profession, neither is it a mature one. Can you truly describe an immature profession as being dead or at best in a state of decline ? Based on the same criteria, couldn't  you describe all other Architect professions (e.g. Business, Solution, Information, Infrastructure etc....) as being less than an overwhelming success ? In my humble opinion, the profession, job title or reporting line is not the issue. EA is firmly grounded on a set of principles/skills/behaviours associated with helping to achieve valuable/measurable Business-IT Linkage. People that exhibit those behaviours should have a firm understanding of both business and IT to be successful in their role and to be honest, there aren't many of these guys out there hence the problem and why I agree to some extent with Veryard and Sprott's blog comments. Secondly, the issue often lies in the word 'Enterprise' which implies the EA might only operate at the 'Enterprise' level, never dipping their toes into business domain areas/projects, primarily focusing on the 'To be' rather than helping to resolve the 'As Is' hence never gaining the credibility to work at the 'Enterprise' level. In my experience, EA's are now focusing more on 'quick win' or strategic company initiatives rather than architecting the enterprise. They have seen the light in the sense that you have to gain credibility in practical 'bite size' chunks (i.e. aimed implicitly at optimizing business processes in stages) and use those smaller (project/program) wins to enhance your reputation in the business. The golden rule here though is to ensure you are not compromising the most effective Enterprise 'To Be' vision through your work/focus on smaller initiatives - i.e. always keep the Enterprise view in mind. Finally, to some extent, the word 'Enterprise' may by some be interpreted as a level of seniority over other disciplines such as Information and Solution Architecture when in fact all of these disciplines are dependent on one another in defining and implementing/governing the ideal future state vision. Let's not start to get excited about the demise of EA. The Business will always require IT to meet its business goals and they will always require a visionary in IT that would help them to succeed in the most efficient use of IT.  However, the following principles need to be applied to get EA back into the 'Circle of trust': Getting the right person exhibit the right skills/behaviours/competencies in the role Second your EA's to the business - more than often, the problem with EA's that they do not sufficient understand the business they work in to give them the credibility to architect for the future. At the recent Open Group Conference in London, the then CIO of Transport for London (TfL) waxed lyrical about the lack of business understanding in the EA team and confirmed he was in the process of seconding his EA's into business facing roles. Ensuring the optimum reporting line to ensure optimum business buy in - it might not be the CIO Ensuring the EA is sufficiently aware of the day to day operational issues and is seen to be suggesting resolutions in those areas (as a set of tactical measures to gain business credibility) as opposed to working in a 'Future state' vacuum Ensuring there is a mechanism that track the metrics associated with the 'value' of EA that is understood and accepted by the business The EA functions works closely with other architectural disciplines - e.g. Information Architects. These professions should be treated as inter-dependent rather than independent. Ensure that the optimum business & IT governance processes are in place so that the professions works closely and effectively together as opposed to against each other Always consider the outcome the business is looking for as opposed to what EA deliverables you think the business might need - all too often, the EA function is delivering shelf ware as opposed deliverables of real business value. Spend time talking to the business about what they expect from you. Ok, its not that simple to implement these principles but they can help to bring the EA back from the dead. We at Oracle still see the value of investing our time in effort in providing thought leadership to the EA community and will continue to do so for the foreseeable future. EA is not yet dead, long live the EA !

In his latest blog post - Is Enterprise Architecture dead - Richard Veryard argues the demise of the role of EA stating: "I can't see much recognition or respect for the value of "Enterprise...

Rethinking Information Architecture for the New World (Part 2)

Last week, in part 1 of this topic, I posed the discussion and some questions around whether it makes sense for traditional enterprises looking to modernize themselves, to reconsider their fundamental perspectives on their information architecture and how they perceive the value of new and growing areas of information inside their enterprise walls. I mentioned organizations like Kaiser Permanente and Washington Post. So, what if we have health care reform pass this year (a big what if), and there is a requirement for HMO’s to comply with some federal standards around patient history and digital medical records. Even if this isn’t necessarily mandated, do we really think that a health care provider can remain competitive in tomorrow’s marketplace without eliminating the inefficiencies of having non-digital patient data records? There are new businesses emerging every day, including Google and Microsoft, who are trying to establish a footprint in the electronic medical records business which they, aptly, see as a very strategic position with significant market power (and profitability) in the future of the health care industry. And in the case of Washington Post, it is experiencing attacks from all side, starting with blogging sites (built upon Google’s Adsense revenue) all way to Craigslist (a website rising to pretty much own one of the most profitable areas of newspaper business - classifieds advertising). This trend will leave Washington Post with holding the most expensive and least profitable area of their business – journalism. I like the HMO and the Newspaper businesses to discuss the value of information architecture because, I believe, these are two business models that are good examples where maintaining the status quo around their information architecture is a likely path for self-obsolescence. Today, if you are in charge of looking after your organization’s information strategy, a lot rests on your shoulders regarding your organization’s future survival. In this hyper information-centric competitive landscape, it is not good enough to achieve operational excellence with your IT infrastructure. It is not good enough to deliver IT capabilities within your IT budget. It is not good enough to meet your SLA’s to the different organizations and functions you serve inside your enterprise. Your role is now becoming larger than that and more strategic, if your organization is to survive against a growing set of information-based competitive attacks. The information acquisition, maintenance and distribution strategy needs to be part of how you compete and how your market yourself.  A CIO has to start thinking less like an IT professional and more like a marketing strategist in the new world. For example, the Washington Post CIO has to figure out how it can use it’s current online subscriber base to enter the world of blogging where they can invite popular bloggers to be part of their information and social networks. Washington Post can lend them their subscriber base’s eyeballs whereas Washington Post could do advertising revenue shares with them. A traditional newspaper could leverage its strengths (e.g. brand and loyal subscriber populations) and be a news platform rather than a new provider. In any case, these are all possibilities if the right information network is built where you are able to execute these kinds of business strategies. My point in all this is not to see yourselves as new white collar people who starts drinking Cognac with the CEO and the CFO and moves into the executive suites and never visits the data center again. No, I am too much of a techie geek to advocate that lifestyle. Instead, I think the two sides of the business must meet more often than it does today and come up with a better strategy that aligns both sides around how the organization treats information. The marriage between business and IT started off in the right way in the nineties when business discovered the power of information and implemented that ERP systems to solve its business automation needs. What has happened is that the business environment has changed considerably over the last decade. But the information strategy has pretty much remained as is. So, today, the business doesn’t feel that IT is truly delivering on their promise while IT feels underfunded and generally neglected. Today, we are reading this blog because we, as architects, have been asked to see if we can fix this marriage. That, by the way, is why are seeing so much discussion and emphasis on enterprise architecture. Enterprise architecture is a basically another name for taking an objective perspective on the causes and sources of misalignments between the business and information technologies. So, the basic challenge, we face today as EA’s, is creating a conversation between the business and IT to share a vision for a common strategy that both sides can agree upon and execute to maximize the chances of success for the entire organization. We can use EA frameworks and methodologies to do this but our focus and objective should be on three basic things: 1. Establish a common language for conversations between business and information technologists (an EA framework usually calls this the business architecture) 2. Define a shared set of principles around how information is treated and leveraged by the business 3. A governance model for course correction when strategies and tactics are not working and need to be rethought. If no 3 had existed, this alignment issue probably would not have been so dire and we wouldn’t need such a major rethink of our information architecture today. We would have course corrected ourselves incrementally over the years, if there was some form of governance around managing alignment between business and information strategies. I guess this is like most human relationships. Sometimes there needs to be a fight before the two sides can figure out a good and lasting answer to their problems.   p.s. In our next part of this topic, we will be discussing those 3 items above and some actionable next steps for your getting your information re-architecture off the ground.

Last week, in part 1 of this topic, I posed the discussion and some questions around whether it makes sense for traditional enterprises looking to modernize themselves, to reconsider their fundamental...

SOA Suite 11g Set Up on Solaris (SPARC)

    I recently helped some folks out with a “recipe” for setting up SOA Suite 11g and OSB (service bus) on Solaris and thought I’d share the information I put together (presented here without warrantee to being perfectly complete/accurate).  Because the versions of WLS being slightly different for SOA and OSB, the install requires 2 WLS instances…not a big deal.   The super-high install flow is 0) Configure database/schemas 1) Install WLS for the SOA Suite ( + correct JDK first) 2) Install SOA Suite pointing to the WLS from step #1 3) Install OSB (which includes WLS) ( + correct JDK first)   For desktop installation, I found this wiki entry that might be useful to keep the number of servers to a minimum: http://wiki.oracle.com/page/Oracle+SOA+Suite+11g:+How+To+Create+All+In+One+AdminServer# Here is my whitepaper on SCA which is relevant to the 11g SOA Suite http://www.oracle.com/technology/architect/entarch/pdf/oracle_sca_the_power_of_the_composite.pdf   Installation Instructions WebLogic http://download.oracle.com/docs/cd/E12839_01/web.1111/e13751/toc.htm#GETST109 SOA Suite http://download.oracle.com/docs/cd/E12839_01/install.1111/e14318/qisoa.htm#BABEIAIA OSB http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/install/index.html Note: During installation, it is important that you use a JDK (and not a JRE) because the installation process assigns values to JAVA_HOME and related variables to point to the JDK directory Databases for both SOA Suite and OSB Oracle 10.2.0.4+ Oracle 11.1.0.7+ You can check all the requirements with the Requirements matrix: http://www.oracle.com/technology/software/products/ias/files/oracle%20fusion%20middleware%2011gr1%20(11%201%201%201%200)%20certification%20matrix.xls Installation packages SOA Suite From the page http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html http://download.oracle.com/otn/nt/middleware/11g/ofm_soa_generic_11.1.1.1.0_disk1_1of1.zip WebLogic version for use under SOA Suite http://www.oracle.com/technology/software/products/ias/htdocs/wls_main.html wls1031_generic.jar (for all 64-bit platforms) You need to have the JDK installed first. Either: Sun 1.6.0_11+ or JRockit 6 Update 5 R27.6.2+ Odds and ends, JDeveloper + RCU.  JDeveloper is only needed for development stations.  I think the RCU is the only other piece that you need, but check. http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html#depends http://www.oracle.com/technology/software/products/jdev/htdocs/soft11.html OSB http://download.oracle.com/otn/bea/osb/osb1031_wls103_solaris32.bin In this case, to use 63, just replace the JDK Specifics for JDK Requirements (32 and 64): http://download.oracle.com/docs/cd/E13196_01/platform/suppconfigs/configs_al10gr3/osb10gr3/overview.html#1133682

    I recently helped some folks out with a “recipe” for setting up SOA Suite 11g and OSB (service bus) on Solaris and thought I’d share the information I put together (presented here without warrantee...

Rethinking Information Architecture for the New World (Part 1)

  Recently, I have been spending a lot of time thinking and trying to understand what the recent trends in economics, technology and consumer behavior means for information and how it should be treated in the new world. The new world that is increasingly being characterized by hyper competition in the online realm. The new world where Facebook is the new way to hang out with friends, the iPhone has replaced reading or writing on paper, Google adsense is almost eliminating the need to read printed information, the overall trend I see is that of massive explosion of electronic data that used to either not get captured (e.g. what comment you made about your friend's new hairstyle) or be captured in physical paper medium (e.g. newspapers and scratchpads). I don't worry so much about Facebook and Google if they are going to be able to handle the new loads and the new volumes of information coming our way. They were born in this age of information madness and so I think they have thought strategies on how to compete and have some method to this madness. The ones I do have concerns for are those enterprises who are trying to make a transition from the world of paper to this new age of digital content, and especially unstructured digital content. I live in Washington DC and so I don't know how well the Washington Post can make the journey from print media to a digital one. How well can Kaiser Permanente jump from being a paper-based HMO to the new world of Electronic Health Records (EHR)? I think the fundamental question is how they see information in their business and how they treat it. Should they continue to treat information as a necessary evil for supporting their business strategies? Or should they be thinking of information and more information and yet more information as a growing asset to their business and a potential ally against competition? I am not sure yet, but thinking it does seem that CIO's of the traditional brick and mortar companies shouldn't necessarily start panicking and sounding the alarms bells on when they see their data centers exploding with new and unstructured content. Instead, they should probably make a few printouts of some samples of the new data flowing into their enterprise, get a cup of decaf and walk over to the CEO's office to brainstorm on strategies and business models on how to harness and exploit the new information for greater benefit to their business. I know that the Facebook and Google CEO's are already chatting on Facebook Chat and Google Groups about this already.

  Recently, I have been spending a lot of time thinking and trying to understand what the recent trends in economics, technology and consumer behavior means for information and how it should be...

Oracle

Integrated Cloud Applications & Platform Services