15 years, 4 days 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.

15 years, 9 days 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 […]

15 years, 30 days 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 […]

15 years, 1 month 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 […]

15 years, 1 month 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 […]

15 years, 1 month 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.”

15 years, 3 months ago

Why Getting Past “But…” is Important

You’ve probably read Getting to Yes and heard of Getting Past No, so why Getting Past “But”? Well, because “but…” is insidious, making it harder to get past than an outright “no.” The person who says “yes, but…” is ostensibly aligning with you. Ostensibly agreeing but for this teensy caveat—this objection that is a showstopper! […]

15 years, 4 months ago

Scaling Agile with VAP: Getting Past “But…”

Our Getting Past “But…” executive report covers two essential areas:

innovation, the circles of innovation model, the innovation process, and what all this means for architects.

scaling agile development projects with VAP (emphasizing just enough design upfront or JEDUF).

These map roughly to the first and second halves of the report, though we encourage those interested […]

15 years, 5 months ago

Video of eXploratory Modelling at ESUG2008 available

Today James Robertson published his video of my talk on eXploratory Modelling at ESUG2008: http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=eXploratory_Modeling_at_ESUG_2008&entry=3404625062 Have fun watching it, and please do not hesitate to contact me if you have questions or if any part of the presentation was unintelligible because of the noise or such.The presentation was done without a microphone, and I guess […]