The Chief Architecture Officer

The first page results for Chief Officer on Google include:

Chief Executive Officer Chief Information Officer Chief Petty Officer Chief financial Officer Chief Happiness Officer ()

ENTERPRISE PORTAL

The next page continues with chief procurement officer, chief security officer, chief operational officer and chief risk officer or chief talent officer are also in use probably to be found a few pages further...

But what about the Chief Architecture Officer?

Architecture is the engineering-art of building and transposed to the business world (business architecture, enterprise architecture, information architecture, what have you) this is about who your organization is built by people, systems, infrastructure, etc.

We continuously build teams and have "constructive" meetings whereas there are also situations where one team is not aware of what the others are doing; what results is double work, half finished projects and contracts all over the work-place where people no longer understand each other.

Understanding is something where language is involved and speaking one language where people from different cultural backgrounds (sales, ICT, human resources, marketing, customer service, operation, distribution) understand each other is a challenge that most organizations have to solve. But are often incapable of.

The language of architecture offers such a format where stakeholders in the process can build each with their background but towards a single construction. "A pattern language," written by the architect Christopher Alexander is one example in the world of physical buildings. But it should also be possible to develop such a language in the business world. If people would only agree on a few guidelines...

Recently I learned about a bank who appointed a risk officer whose job it was to see whether the profile of a new business (development) would really fit the risk-return profile of the company. These things have never been an issue, but it is one of the first activities of architecture; the check whether business activities fit the profile of the organization.

I don't think that a company should introduce roles or function of architects, like business architect or information architect, or enterprise architect... as long as what is being build fits what is needed. That your organization is supporting the right business in an efficient and effective way.

The Chief Architecture Officer... something to consider?

The Chief Architecture Officer

© 2009 Hans Bool

ENTERPRISE PORTAL

SharePoint - The New Face of Your Enterprise Architecture

Business Users today have to operate on tens, if not hundreds of applications, as part of their daily routine to run through their quota of work, moving from one silo to another to another, and if that isn't enough, the increased application access and password complexity, making it absolutely hard to maintain focus on their core jobs. Add to that, a lack of interoperability between these systems, and a lack of a truly integrated experience, and you've just defined virtual hell. Not to mention, the virtual nightmare that it is, for the IT departments, to manage and maintain these varied platforms and applications on a day to day basis.

In a world where the focus has moved from "one solution for all " to "doing one thing, and doing it right", vendors are building software solutions that meet some specific need and Enterprises, in an attempt to stay current, and to give their employees the best-of-the-breed software end up bringing in a myriad of applications and platforms within their environments. The result: "Virtual Hell".

ENTERPRISE PORTAL

Positioning of SharePoint as a Business Platform

SharePoint Features and Benefits

- Provides out of the box collaboration features like blogs, wikis, discussions, project management, document libraries, lists etc., that are easy to use and allow information workers to share and manage contents.
- Allows building applications that are supportable, extensible and easily maintainable by business users
- Workspace templates along with the collaboration tools can be used to manage specific information about projects, IT, HR etc.,
- Advanced Document management capabilities with support of content types allow information workers to easily create documents, fill information and share them securely.
- Can be a single platform for Intranet, Extranet and Internet with support for hosting to provide applications and software as service
- Supports collaboration both within the internal users, external users, and anonymous users of the Enterprise.
- Supports out of the box reporting dashboards, KPI web parts etc. that can be used to build mash ups and integration with backend systems
- Offers a component, the Business Data Catalog that allows for integration of LOB systems with SharePoint, and surfacing the data from within these disparate systems, right into SharePoint.

SharePoint is a great platform for building robust and flexible Enterprise 2.0 solutions that are extensible and secure, and leverage Web 2.0 in a holistic fashion to empower business users, and help organizations become more agile, efficient and productive, all in a seamless and secure fashion. Common areas where Enterprise 2.0 solutions prove particularly useful are IT helpdesk, Active Directory user provisioning and profile management, eProcurement and the like. Well designed Enterprise 2.0 solutions virtually become key strategic assets for any organization's business performance.

SharePoint - The New Face of Your Enterprise Architecture

OptimusBT, a Microsoft Gold Certified Partner is a global leader in providing Business solutions that are primarily SharePoint based and utilize existing client infrastructure. For over 5 years, OptimusBT has paved the road when implementing complex, global solutions in the areas of Sales, Finance, Procurement, Manufacturing, Human Resources, and others across industry segments around the world.

ENTERPRISE PORTAL

How to Grasp High Level & Fundamental Understandings of SAP System Architecture?

It is an undeniable fact that SAP gains more and more customers such as big US and global Corporations and government. SAP's greatest opportunity probably lies beyond Microsoft or IBM or Oracle. SAP AG is a global software company headquartered in Walldorf, Germany. SAP simply stands for Systems Applications and Products in Data Processing. It will be highly worthwhile to go over the essential components of SAP System as more and more companies are moving toward using ERP package such as SAP rather than relying on traditional in-house development of Corporate Application Systems.

First, there is R/3 or ERD or ECC. The name of this component has been evolved, but the essential function of system component has not changed much. ERP stands for Enterprise Resource Planning Software product SAP AG.

ENTERPRISE PORTAL

This component has its own several sub-modules such as MM (Material Management), SD (Sales Distributions), FI/CO (Financial and Costing and Billing), PM (Plant Maintenance/Production Planning), WM (Warehouse Management) and HR (Human Resource Management). It has Workbench environment where staff can develop customized program using ABAP programming and database tables to support companies' own internal business processing. Each sub modules support many screens/transactions and reporting transactions to easily keep track of inventory, orders, movement of goods. Either Business customers or traditional IT staff can relatively merge together to design and develop various business processes. ECC (Enterprise Central Component) is recent name for R/3 or ERD. Even huge company can be sufficiently supported by this one component.

Second component is called APO (Advanced Planning & Optimization). This component is all about planning using demand data and the power of forecasting. Forecasting is one of core sub-modules, and Planning is based on sophisticated planned data which is forecast data. The name SCM (Supply Chain Management) is also used interchangeably to refer APO component. However, please remember that SCM itself is a generic term and discipline that is taught at major university or institution. DP (Demand Planning, i.e. Forecasting) and SNP (Supply Network Planning) are major sub-modules of APO/SCM. It is interesting to note that as the SAP gains more popularity among companies, SAP is currently adding Industry-unique modules called SPP (Service Part Planning) with cooperation of major US Auto Industry (Ford) and CAT-Logistics.

Third piece is CRM (Customer Relation Management). This component is most likely corresponding to Traditional Customer Order Processing System. Customers can place orders, and orders are processed by CRM. Customer data and Order data and material data are keys to manage this component.

There are also many layers/tools that are interfaced with above three components. For instance, ICH (Inventory Collaboration Hub), EWM (Extended Warehouse Management under SCM), XI (Exchange Infrastructure), BI (Business Intelligence) and EP (Enterprise Portal) could be those. SAP connects above three components using CIF (Core InterFace between ECC and SCM) and CRM Middleware (between ECC and CRM) to enhance data integrity and connectivity.

Author attended several SAP classes in MM, SCM and Customizations provided by SAP AG. As there are still strong demands for SAP system and classes, it is hoped that more affordable training classes and materials will be available by other training agencies very soon.

How to Grasp High Level & Fundamental Understandings of SAP System Architecture?

For more information about SAP, Please visit http://www.sapSuccess.blogspot.com

ENTERPRISE PORTAL

Chief Architect's Big Three Secrets For Enterprise Architecture Planning

In a previous article "Chief Architect's Big Three Strategic Secrets", the spotlight fell on three biggest risks the Chief Architect needs to manage before moving onto something less tactical. Consider now the area of strategic planning and opportunities in your future state landscape. Three key sources that the chief architect needs to explore are:

CEO's Top Strategic Drivers CIO's Primary Concerns Enterprise Portfolio Management

ENTERPRISE PORTAL

In fact, the CEO owns, knows, eats and breathes their top three strategic drivers. At a time in the economy that we are facing now pure survival may likely be their number one focus. Such drivers might include the area cost savings, as well company stock prices. The chief architect needs to fully understand how these drivers impact or are impacted by the Enterprise Architecture Plan.

Choices made in the areas of infrastructure and solutions will most likely be efficiency based, and risk averse. Creatively considering ways in which the architecture can contribute in the area of competitive tactics is another way in which we can provide value. If the CEO is really focused on their competition's moves, it might be a looming takeover or collapse. How can the strategic plan allow for agility in these types of circumstances? What would it take to expend with a line? A division? Or purchase either?

An additional area of CEO concern is major projects. The CEO realistically needs to keep aware of the biggest corporate expenditures and these may be IT projects. Characteristically these are very high profile projects or large replacement projects. The chief architect should be fully aware of what the CEO's concerns are, and what it is troubling them about the projects. It may be the board's opinion of the project, and where else the money could be better spent.

The second area the chief architect needs to focus on is the concerns of the CIO. It is crucial to have a list of things that keeps this soul up at night as well. Some risky hardware component or some recent security lapse could be top of the list. It might be an employee or staffing issue. Where they are privy, the chief architect needs to explore what can be done in upcoming plans.

Ultimately there is the major issue of job retention as a CIO. Budget cuts and less than stellar IT performance can be used as stimulus to look within the large resource pool available. What can be done to ensure IT performance is not a factor.

A major area of concern to the chief architect should always be enterprise portfolio management. This is the prime source of where strategic future directives will be exposed. The architect needs to comprehend and be fully aware at all times of the biggest opportunities. What was the biggest project or investment identified? What is on that list or that requires the biggest investment AS WELL as the biggest return on investment.

I would suggest that the chief architect to quickly scan that portfolio management list on a monthly basis and retain a list of the quick wins and low hanging fruit. Each of these should be incorporated into whatever future planning is being pursued as the opportunities are available.

You've got to keep the pulse on these critical elements - and keep this in on your laser focus. Continually update your enterprise architecture plan where you can whenever these strategic drivers change.

Happy Architecting!

Chief Architect's Big Three Secrets For Enterprise Architecture Planning

Sharon C. Evans is an Enterprise Architect Coach, Mentor and Trainer. Her forthcoming book "Zoom Factor for Enterprise Architects: How to Focus and Accelerate Your Career" focuses on excellence and perspective for the Enterprise Architect and is due out in November 2009. She is the founder of Firefli Consulting Inc. and her member portal and more great articles and training schedules can be found at http://www.architectbootcamp.com

ENTERPRISE PORTAL

Software Architecture Principles

In my day to day role, I am architecting enterprise business applications using multiple COTS product(s) and creating solutions around them.

Following are the architecture principles I tend to stick to when architecting solutions:

ENTERPRISE PORTAL

KISS (Keep it Simple and Stupid) - First cardinal rule I always follow is to keep the architecture simple. I make sure that I do not use jargons or abbreviations that require Googling every 2nd word. I create multiple views of the architecture for different stakeholders (IT, Business, Implementation Team, Infra Team and so on) to convey the design and architecture Buy vs Build Decision - I generally in favor of buying the functionality instead of trying to re-invent the wheel. I recommend not falling in the trap of "not invented here" syndrome to start creating everything in-house. Requirement Mapping - When using COTS (Commercial Off The Shelf) products in your design, make sure you have mapped your requirements to the product features. Use a COTS product only, if it fulfill 70-80% of the requirements out of box Identify Integration Points - When you are dealing with multiple COTS products, it is very important to identify the integration points for those products. If you even an iota of doubt, do a proof of concept to validate the same. Do not go by the product brochures, or sales talk. There is nothing like knowing what works and what does not early in the game Decision Making - In any architecture design, decisions need to be made. Usually people do not want to stick their neck out. I believe in taking decisions based on the information and data available and moving ahead. I might be wrong but at least we move ahead. If the decision was wrong, we correct it on the way. I do not believe in wasting time in endless meetings that do not lead anywhere. I also make a point to validate my decisions by doing proof of concepts to validate some of the technical design issues Stakeholders - In any solution design, make sure you are aware of your stakeholders. The stakeholders might be direct like Business, Development Team or may be indirect like IT Team, Infra Team, Hosting vendors and Maintenance team. Make sure you share and get feedback from stakeholders on your architecture to avoid any unpleasant surprises later on Prepare for change - We might always want the requirements to be cast in stone, but seldom they are. To tackle the uncertainty, I try to view requirements as what can potentially change vs what will not change. Design for requirements that are not likely to change (e.g. logging, auditing, persistence mechanism, messaging etc). For the requirements that keep changing (e.g. HTML look and feel, content layout etc) be prepared with a design that is fluid and ready to accommodate changes. If you are aware of areas of change and are expecting changes in that area's, it will be easy to accommodate them Communication - Communication of architecture to the entire stakeholder team is very important. The stakeholder's include both internal and external teams. On the client side you will have Business, IT, Infra, Security, Enterprise teams. On the other side, you will have your own PMO, Development team, testing team, deployment Be prepared for surprises - Whatever you do, you still need to be prepared for surprises. Make sure you plan for the same. I have not done a single solution where you do not come across at least one surprise Enjoy - in the end, do not get bogged down. Enjoy the work. People will appreciate the same!

These things work me. Do share what works for you!

Software Architecture Principles

Tech Spot is my den where I jot my thoughts on the Technology landscape. I blog my experiences in the J2EE World and my word on some of the happenings in the Tech world.

Focus Areas - Portal Servers, Application Servers, Web Services, SOA, Web 2.0 and Enterprise 2.0

ENTERPRISE PORTAL