Pages

Thursday, June 16, 2011

Information that can be important when your are trying to understand Enterprise Architects

 

This was taken from a website.. Is just a glossary of common words that everybody need to keep in mind

 

Glossary

  • ADM (Architecture Development Method)—A process for creating an enterprise architecture that is part of the TOGAF standard.
  • application architecture—The architecture of a specific application.
  • architect—One whose responsibility is the design of an architecture and the creation of an architectural description.
  • architectural artifact—A specific document, report, analysis, model, or other tangible that contributes to an architectural description.
  • architectural description—A collection of products (artifacts) to document an architecture.
  • architectural framework—A skeletal structure that defines suggested architectural artifacts, describes how those artifacts are related to each other, and provides generic definitions for what those artifacts might look like.
  • architectural methodology—A generic term that can describe any structured approach to solving some or all of the problems related to architecture.
  • architectural process—A defined series of actions directed to the goal of producing either an architecture or an architectural description.
  • architectural taxonomy—A methodology for organizing and categorizing architectural artifacts.
  • architecture—The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution (from IEEE-1471-2000).
  • business architecture—An architecture that deals specifically with business processes and business flow.
  • business reference model (BRM)—An FEA term that gives a business view of the various functions of the federal government.
  • business services segment—An FEA term that refers to a segment that is foundational to most, if not all, political organizations, such as financial management.
  • CIO—Chief Information Officer, the executive in charge of information technology in a corporation.
  • CIO Council—A council consisting of CIOs from each of the federal governmental agencies that coordinates work related to common interests.
  • Clinger-Cohen Act of 1996—See Information Technology Management Reform Act.
  • common-systems architectures—A TOGAF term referring to an architecture that is common to many (but not all) types of enterprises, in contrast to foundation architectures and industry architectures.
  • component reference model (CRM)—An FEA term that gives an IT view of systems that support business functionality.
  • data architecture—The architecture of the data (typically stored in databases) owned by the enterprise.
  • enterprise architect—An architect who specializes in enterprise architectures.
  • enterprise architecture—An architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise.
  • enterprise service—An FEA term referring to a well-defined function that spans political boundaries, such as security management.
  • FEA—See Federal Enterprise Architecture (FEA).
  • FEAF—See Federal Enterprise Architectural Framework (FEAF).
  • FEAPMO—The organization within the OMB that owns and administers the Federal Enterprise Architecture.
  • Federal Architecture Program EA Assessment Framework—A benchmark used by the OMB to measure the effectiveness of governmental bodies in using enterprise architecture.
  • Federal Enterprise Architectural Framework (FEAF)—An enterprise-architectural framework used by the U.S. federal government to describe how the various governmental agencies and their IT systems are related to each other.
  • Federal Enterprise Architecture (FEA)—An architectural description of the enterprise architecture of the U.S. federal government that includes various reference models, processes for creating organizational architectures that fit in with the federal enterprise architecture, and a methodology for measuring the success of an organization in using enterprise architectures.
  • foundation architecture—A term used by TOGAF to refer to the most generic of architectures that can be used by any IT organization, in contrast to common systems architectures.
  • GAO—See General Accountability Office (GAO).
  • Gartner—An IT research and advisory organization.
  • gateway—A transfer point of an autonomous system from which messages from the outside world are received or through which messages to the outside world are sent.
  • General Accountability Office (GAO)—A branch of the U.S. Government that is responsible for monitoring the effectiveness of different organizations within the U.S. Government.
  • industry architecture—A TOGAF term that refers to a architecture that is common to most enterprises within an industry, in contrast to a common-systems architecture and an organizational architecture.
  • Information Technology Management Reform Act—An act passed by the U.S. Congress in 1996 that requires all governmental organizations to use effective strategies and frameworks for developing and maintaining IT resources.
  • OMB (Office of Management and Budget)—Part of the Executive Office of the President of the U.S. that serves the function of presidential oversight on federal agencies.
  • The Open Group Architectural Framework—See TOGAF (The Open Group Architectural Framework) 8.1.
  • organizational architecture—A TOGAF term that applies to an architecture that is specific to a particular organization, in contrast to an industry architecture.
  • performance reference model (PRM)—An FEA term that gives standard ways of describing terms related to measuring value.
  • Return on Investment (ROI)—A measure (in percent) of the business value of a project, based on the increase in profit (either because of increased income or decreased expenses) divided by the cost of the project. For example, a project with a cost of $100,000 that returned $200,000 in increased profit has an ROI of 200 percent.
  • ROI—See Return on Investment (ROI).
  • segment—An FEA term that refers to a major line-of-business functionality, such as human resources, that might be shared across organizations.
  • standards information base (SIB)—A TOGAF term that refers to a collection of information about standards, particularly in the area of open-source.
  • TAFIM (Technical Architecture Framework for Information Management)—An architectural framework developed by the Department of Defense and officially discontinued in 2000.
  • technical architecture—Usually refers to the architecture of the technical infrastructure within which applications run and interact.
  • technical reference model (TRM)—Part of TOGAF, a reference model that gives a common language for various pieces of IT architecture. This term is also used for a similar meaning within FEA.
  • TOGAF (The Open Group Architectural Framework) 8.1—An architectural methodology that is controlled by The Open Group.
  • Zachman Framework for Enterprise Architectures—An architectural framework in which an enterprise is modeled as 30 or 36 cells, each of which represents an intersection between a stakeholder perspective and an abstraction.

Thursday, January 27, 2011

ORACLE BUSINESS DAY IN SAN JUAN, PUERTO RICO

 

 

Oracle Corporation

Oracle Day 2011 - See. Learn. Meet. All Here

Información

Conferencistas

Agenda

Patrocinadores

 

CONOZCA los nuevos productos y soluciones de negocios
APRENDA las más importantes tendencias y desarrollos
REÚNASE con expertos, proveedores, líderes de negocios e innovadores

Oracle Caribbean por tercer año presenta el OracleDay 2011, nuestro evento ejecutivo de tecnología y soluciones empresariales más grande del año. Envuélvase en la innovación operacional y tecnológica que mantiene a empresas y organizaciones en constante agilidad, éxito y crecimiento.
Maximice el éxito de su organización manejando estratégicamente su información.
Comenzamos la tarde con reconocidos conferenciantes que abordan nuestro completo ofrecimiento, visión estratégica y beneficios para su organización; así como también presentaciones enfocadas a innovación tecnológica y operacional.

  • Visualice las tendencias económicas e identifique las oportunidades en el mercado actual por Gustavo Vélez, Economista y Presidente de Inteligencia Económica Inc.
  • Participe de la conferencia: Trayectoria y Éxito Empresarial por Ing. Miguel A Cordero, Director Ejecutivo de la Autoridad de Energía Eléctrica

Participe de sesiones específicas para la optimización y eficiencia tecnológica, soluciones empresariales y herramientas de análisis para la toma de decisiones.

  • Cloud Computing, la nueva arquitectura empresarial
  • Oracle Exadata, alcanzando el desempeño extremo
  • Soluciones empresariales Oracle: El nuevo estándar de aplicaciones de negocio
  • CRM como herramienta estratégica
  • Oracle Business Intelligence: logre una excelencia operacional con herramientas de análisis para la toma de decisiones

No se pierda el OracleDay 2011. Cualesquiera que sean sus retos operacionales o desafíos de IT, encuentre las respuestas en este evento.
Regístrese ahora en línea para este evento libre de costo. Para mayor información o registro puede llamar al 787.999.3154 ó escriba a eventoscaribe@meridianisas.com

Regístrese Ya

Regístrese ahora en línea para este evento libre de costo.

11 de febrero de 2011
1:00 p.m. - 7:00 p.m.
Centro de Convenciones de Puerto Rico
San Juan, Puerto Rico
7:00 p.m. - 8:00 p.m.
Coctel y sorteos amenizado por Jukebox

Jukebox

Si usted es empleado o funcionario de una entidad de gobierno, por favor, haga click aquí para acceder a información ética relevante respecto de este evento.

Hardware and Software Engineered to Work Together

Copyright © 2011, Todos los Derechos Reservados.

Contáctese | Avisos Legales y Términos de Uso | Declaración de Privacidad

Saturday, October 16, 2010

How to report laptop demos in ADS- DSS

As part of our target of report our  demos in ADS – DSS, we mustto define all of them in ADS – DSS as laptop – Not Network demo. As shown below.

 

image

Wednesday, October 6, 2010

Oracle has posted a BPM Tutorial

 

SOA Suite logo Pre-built Virtual Machine for SOA Suite and BPM Suite 11g

Overview

Please note that this appliance is for testing purposes only, as such it is unsupported and should not to be used in a production environment.

This VirtualBox appliance contains a fully configured, ready-to-use SOA/BPM 11g R1 installation.

All you need is to install Oracle VirtualBox on your desktop/laptop and import the SOA/BPM appliance and you are ready to try out SOA 11g including the recently released BPM 11g -- no installation and configuration required!

The following software is installed in this VritualBox image:

  • Oracle Enterprise Linux 5 Update 4
  • Oracle XE Universal database 10.2.0.1
  • Oracle WebLogic Server 10.3.3.0
  • SOA Suite 11gR1 PS2
  • BPM Suite 11gR1 PS2 (with bundle patch #1)
  • BAM 11gR1 PS2
  • B2B 11gR1 PS2
  • JDeveloper 11.1.1.3

Please follow the instructions below for downloading and importing the VirtualBox image.


Requirements
  • At least 3GB of RAM
  • At least 30GB of free disk space. (Note: virtualization works best with contiguous space so it is a good idea if on Windows to run a defrag program, and make sure you are using NTFS for your file system to handle large files on Windows
  • 2GHz processor

Setup


Learn More

Getting Started With Oracle BPM Suite 11g R1: A Hands-On Tutorial book cover
Getting Started With Oracle BPM Suite 11g R1: A Hands-On Tutorial
Learn from the experts – teach yourself Oracle BPM Suite 11g with an accelerated & hands-on learning path brought to you by Oracle BPM Suite Product Management team members.
by Heidi Buelow, Manoj Das, Manas Deb, Prasen Palvankar, Meera Srinivasan

Complete information can be reached here: http://www.oracle.com/technetwork/middleware/bpm/learnmore/index.html

Note: Information taken from Oracle Websites

Definitions for understand SOA

 

Note: Information taken from many places specially from:

http://blogs.msdn.com/b/nickmalik/archive/2007/06/12/canonical-model-canonical-schema-and-event-driven-soa.aspx

Definitions: 

  • Cohesion (Acoplamiento in spanish)- Software cohesion is the level of association between two or more elements.  Traditional design principles focus in High Cohesion.  SOA promotes loose coupling at all levels but SOA, in light of the levels defined above, actually requires low cohesion to be successful.

 

  • Enterprise Canonical Data Model - The data we all agree on.  This is not ALL the data.  This is the data that we all need to agree on in order to do our business.  This is the entire model, as though the enterprise had one and only one relational database.  Of course, it is impossible for the enterprise to function with a single database.  So, in some respect, creating this model is an academic exercise.  It's usefulness doesn't become apparent until you add in the following concepts, so read on.

 

  • Canonical Message Schema - When we pass a message from one application to another, over a Service Oriented Architecture or in EDI or in a batch file, we pass a set of data between applications.  Both the sender and the reciever have a shared understanding of what these fields (a) data type, (b) range of values, and (c) semantic meaning.  The first two we can handle with the service tools we have.  The third one is far and away the hardest to do, and this is where most of the cost of point-to-point integration comes from: creating a consistent agreement between two applications for what the data MEANS and how it will be used.

 

  • Event Driven Architecture -  Architecture pattern promoting the production, detection, consumption of, and reaction to events.  A style of  architecture characterized by the development of a set of relatively independent actors who communicate events amongst themselves in order to achieve a coordinated goal.  This can be done at the application level, the distributed system level, the enterprise level, and the inter-enterprise level (B2B and EDI).

            http://en.wikipedia.org/wiki/Event-driven_architecture 

 

  • Business Event Ontology -- A reasonably complete list of business events, usually in a hierarchy, that represents the points in the overall business process where two "things" need to communicate or share.  I'm not referring to a single event, but rather to the entire list.  Note that a business event is not the same as a process step.  An event may trigger a process step, but the event itself is a "notification of something that has occurred," not the name of the process we follow next.


I guess what escaped me, until recently, was how closely related these concepts really are.
The way I'm approaching this starts from the business goal: use data to drive decisions.  Therefore, we need good data.  In order to have good data, we need to either integrate our applications or bring the data together at the end.   Either way, if the data is used consistently along the way, we will have a good data set to report from at the end.
To create that consistency, we need the Enterprise Canonical Data Model.  Creating this bird is not easy.  It requires a lot of work and executive buy-in.  Note that the process of creating this model can generate a lot of heated discussions, mostly about variations in business process.  Usually the only way to mitigate these discussions is to create a data model that contains either none of the variations between processes, or contains them all.  Neither direction is "more correct" than the other.

However, in order to integrate the applications, either along the way or at the end of the data-generation processes, we need to use a particularly constrained definition of Canonical Schema: the Enterprise Canonical Message Schema is a subset of the Enterprise Canonical Data Model that represents the data we will pass between systems that many people feel would be useful. Note that we added a constraint over the definition above.  Not only are we sharing the data, but we are sharing the data from the Enterprise CDM.

By constraining our message schema to the elements in the Enterprise Canonical Data Model, we radically reduce the cost of producing good data "at the end" because we will not generate bad data along the way.  The key word is "subset."  In order to create a canonical schema without a canonical data model, you are building a house on sand.  The CDM provides the foundation for the schema, and creating the schema first is likely to cause problems later.
Therefore, for my friends still debating if we should do SOA as a "code first" or "schema first" approach, I will say this: if you want to actually share the service, you have no choice but to create the service "schema first" and even then, only AFTER a sufficiently well understood part of the canonical data model is described and understood.

And for my friends creating schemas that are not a subset of the overall model, time to resync with the overall model.  Let's get a single model that we all agree on as a necessary foundation for data integration.
The next relationship is between the Canonical Message Schema and the Event Driven Architecture approach.  If you build your application so that you are sending messages, and you want to create autonomy between the components (goodness), you need to send data that has a well understood interpretation and as little 'business rule baggage" as you can get away with.  What better place than the Canonical Data Model to get that understanding?  Now, this is no longer an academic exercise. 

Creating the enterprise level data model provides common understanding, so that these messages can have clear and consistent meaning.  That is imperative to the notion of Event Driven Architecture, where you are trying to keep the logic of one component from bleeding over into another.

The business event ontology defines the list of events that will occur that require you to send data.  Creating an ontology requires that you understand the process well enough to generalize the process steps into common-held sharable events.  To get this, the data shared at the point of an event should be in the form of an Enterprise Canonical Message Schema.

Therefore, to summarize the relationship:
  Business Events occur in a business, causing an application to send a Canonical Message to another application.  The Canonical Message Schema is a subset of the Canonical Data Model.  Event Driven Architecture is most efficient when you send a Canonical Message Schema message between components.  This provides you with more consistent data, which is better for creating a business intelligence data warehouse at the end.

Some agility notes:
The list of business events in a prospect ontology may include things like "receive prospect base information", "receive prospect extended information", "prospect questionnaire response received", "prospect (re)assigned", "prospect archived", "prospect matched to existing customer", "prospect assigned to marketing program," etc. It is not a list of process steps.  Just the events that occur as inputs or outputs.

Clearly, this list can be created in iterations, but if it is, you need to make sure that you capture all of the events that surround a particular high level process and not just focus from technology.  In other words, the business processes of "qualify prospect" or "validate order" may have many business events associated with them, and those events may need to touch many applications and people.  If you decide to focus on "qualify prospect" first, then understand all of the events surrounding "qualify prospect" before moving on to "validate order," but if both processes hit your Customer Relationship Management system, focus on the process, not the system.

Tuesday, October 5, 2010

001 - Understanding the Architecture behind Technologies

One of the first step to understand any technology architecture is to have some background knowledge and understand terminology.  To do so, I will be here sharing information that you can get browsing the internet.

 

Soon Very Soon