10 years, 10 months ago

Keep an eye on OneCMDB and the CMDB Federation

OneCMDB Version 2.0 is a real interesting concept and product as this may be one of the first IT Service Management solution developed in an Open Source mode. It will not replace your Service Desk solution but may help companies with limited budget or companies which have a wide diversity of existing catalogs of assets. It is only covering Configuration Management as a process and in some way IT Assets management. For those who are using Nagios, there exist some connectors.

This has been initially developed by Lokomo Systems using Java but I’m not sure how does that fit with the CMDB Federation Group (I wrote a post on the subject in 2007) if it still exists….(I haven’t seen any indication of activity since January 2008 and maybe this is a dead project…).

In any case, keep an eye on both…
10 years, 10 months ago

Keep an eye on OneCMDB and the CMDB Federation

OneCMDB Version 2.0 is a real interesting concept and product as this may be one of the first IT Service Management solution developed in an Open Source mode. It will not replace your Service Desk solution but may help companies with limited budget or companies which have a wide diversity of existing catalogs of assets. It is only covering Configuration Management as a process and in some way IT Assets management. For those who are using Nagios, there exist some connectors.

This has been initially developed by Lokomo Systems using Java but I’m not sure how does that fit with the CMDB Federation Group (I wrote a post on the subject in 2007) if it still exists….(I haven’t seen any indication of activity since January 2008 and maybe this is a dead project…).

In any case, keep an eye on both…
10 years, 10 months ago

Deliverables, Artifacts And Catalogs-Matrices: Some examples

Quite often as an Enterprise Architects we are asked to show what the deliverables of an Enterprise Architecture program are.

TOGAF provides a methodology for analyzing your specific situation and turning that analysis into deliverables and actionable artifacts. Artifacts may have different shapes as defined in TOGAF 9. They may be: Catalogs, matrices or diagrams. EA artifacts may also help to define a standard set of document types such as education, strategy, decision, policy, standard, guideline, etc. It is also recommended that you set up a simple online discussion thread or wiki for each artifact to solicit feedback from artifact consumers.

Enterprise Architects should ensure that their efforts to create architecture documentation produce meaningful results by creating artifacts that connect with the consumer, drive decisions, and will allow the development of reusable building blocks.

If we consider the various architecture domains, they may have different forms.

As examples-
in Business Architecture, they could be the views of the Business stakeholders. The matrices between business strategy and the main business functions. The diagrams showing the relationship between processes and information. The Value Chains. Business and Operating models of the Enterprise. Customizing the configuration of the Business Functions according to model — and more.

The artifacts for Data or Information architecture may refer to an information map or diagram . It could also show the mapping between data items and the Business Information map.

Artifacts for Application Architecture, could show the key interconnections between applications, middleware connection matrices. There may also exists views for Portal Architecture, Enterprise Content Management , Identity management, Business Intelligence, ERPs and CRMs.

Last but not least, Technology Architecture artifacts may propose servers and storage technology diagrams, office views (file, printing, data base servers, etc…), LAN/WAN/Voice Network architecture diagrams, applications and interconnections mapping to technology servers and networks, infrastructure security diagrams. In addition to that, there may be a certain numbers of artifacts related to the company’s organization, organization chart, lines of business mapping to business functions, organization roles in organization units and job descriptions.
Many graphical tools may aid to develop diagrams or document matrices but may also be quite costly. The use of spreadsheet may be a first step in building artifacts such as matrices. The following examples illustrate how they may simply be build with Excel.

List of Metadata

Data-Business process matrix
Application Inventory List

These are very basic example of what artifacts may look like. They may rapidly be created and are definitely a way to explain to the EA stakeholders how the first deliverables of our baseline architecture looks like.

10 years, 10 months ago

Modeling the MDM Blueprint – Part V

In this series we have discussed developing the MDM blueprint by creating Common Information (part II), Canonical (part III), and Operating (part IV) models in our work streams. We have introduced the Operating Model into the mix to communicate how the solution will be adopted and used to realize the benefits we expect with the […]

10 years, 11 months ago

Modeling the MDM Blueprint – Part IV

In part II and III of this series we discussed the Common Information and Canonical Models. Because MDM is a business project we need to establish of a common set of models that can be referenced independent of the technical infrastructure or patterns we plan on using. Now it is time to introduce the Operating […]

10 years, 11 months ago

Modeling the MDM Blueprint – Part III

In part II of this series we discussed the Common Information Model. Because MDM is a business project we need to establish of a common set of models that can be referenced independent of the technical infrastructure or patterns we plan on using. The essential elements should include: – Common Information Model – Canonical Model […]

10 years, 11 months ago

Modeling the MDM Blueprint – Part II

In part I of this series we discussed what essential elements should be included in a MDM blueprint. The important thing to remember is the MDM is a business project that requires establishing of a common set of models that can be referenced independent of the technical infrastructure or patterns you plan on using. The blueprint […]

10 years, 11 months ago

Inappropriately comparing Building Architecture and Software Architecture

Mike Walker wrote a great little article describing that it is largely inappropriate to compare Software Architecture and Building Architecture professions – see here. I think Mike has a great point that the two types of architecture disciplines are so different that it’s hard to rationally compare the two.

Mike’s blog reminded me my wife’s comments on article titled “If building architects had to work like IT architects” written a couple of years ago. By the way, my wife is a commercial and residential Building Architect. Anyway, in that article, Katheryn felt it inappropriately assumed similarities of Software Architecture and Building Architecture to the point she felt compelled to comment and help explain that the article’s author is probably not too knowledgeable of the Building Architecture profession.

Note: Although I feel it is largely inappropriate to compare the two professions, I wish we could. Unfortunately, as Mike points out, Software Architecture is just way too immature a profession at the moment.

Here’s a repost of my wife’s comments to the “If building architects had to work like IT architects” article. Katheryn Morgan wrote:

“The article is misleading because your IT projects are better related to a commercial non- personal project. Your clients would be equivalent to a developer not an individual looking for a personal residence. It can be done different ways, but this way is very common:

Initial Design

If the client is really unsure of what he wants and only has a vague idea and he wants to see some ideas first then he is paying for the head designer’s experience. The team is made up of different experienced architects and workers. Each person’s time is charged to the client at a different rate. Just like consulting, we have to assign our time to each project. The head designer would charge more per hour than the person assigned to draw it up. The more re-draws based on the clients wishy-washy-ness the more money they are being charged. The client is charged for mileage for site visitations, city department visits etc. Once a design has been agreed on (the project can easily be, and often does get nixed because the client has not acquired the site for the project or the investors have backed out or there are problems with the city allowing such project etc. You can convert any of these problems into your IT world I’m sure) then there is a next phase of costs.

Documentation Phase

The client will be charged by how many sheets of documentation is required for the project to go to a contractor to get sufficient bids for cost of construction. The lead architect by experience should know how many sheets would be required based on the size of the project. The client is also charged for all printing and mailing costs.

Construction Documentation Bidding

The documents are sent to several prospective contractors chosen by the architects and sometime by the clients, as they have probably worked with some before and others chosen because of their direct experience with this particular type of project. The builders bid this project on the hopes they will receive the project and no money is charged by them. The winner is the one who comes back with the best realistic construction cost and can generally show a realistic construction time line with milestones that they are held accountable for and they receive partial payments as long as those milestones are reached. There can also be a bonus incentive for them to finish on time (which rarely happens). This process is kept in strict confidence and the architect never reveals to the other builders what the others bid was.

Construction

Here is a key point different to your world: the designers and the constructors (builders) are different entities. The architect’s role here is to see to the client’s BEST interest. the architects answers RFI’s and does site visits to ensure the vision of the project is coming to fruition. The architect answers requests for payment by checking if the milestones have been met, reporting progress to the clients and if the client is satisfied he will approve payment, and the architect will pay the builder.
At the end of the project the architect does a walk thru with the client and builder and any things that need fixing are written and given to the builder. He has to finish these last things before a certificate of occupancy is issued and the builder is given his last payment and any incentive bonus. The architect is also in charge of getting all permits from the city and any official requirements so the client can easily transition.”