architectbootcamp.com » Skills http://architectbootcamp.com Promoting Information Architecture Excellence Mon, 19 Dec 2011 16:27:47 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 The Architecture Blueprint Component http://architectbootcamp.com/architect-skills/the-architecture-blueprint-component-checklist/ http://architectbootcamp.com/architect-skills/the-architecture-blueprint-component-checklist/#comments Thu, 30 Apr 2009 16:24:58 +0000 superfli http://enterprisearchitecturecoach.com/?p=268 This checklist should be used when creating an Architecture Blueprint document, or blueprint style documentation.

Each major bullet represents a section.  Sub-bullets may represent further drilled down sections.

]]> http://architectbootcamp.com/architect-skills/the-architecture-blueprint-component-checklist/feed/ 0 Architecture Roles & Skills http://architectbootcamp.com/architect-skills/architecture-roles-skills/ http://architectbootcamp.com/architect-skills/architecture-roles-skills/#comments Sat, 17 Jan 2009 16:19:21 +0000 superfli http://enterprisearchitecturecoach.com/?p=263 RolesSkillsMatrix1RolesSkillsMatrix2RolesSkillsMatrix3

]]> http://architectbootcamp.com/architect-skills/architecture-roles-skills/feed/ 0 Ethics Skills in IT Architecture http://architectbootcamp.com/architect-skills/ethics-skills-in-it-architecture/ http://architectbootcamp.com/architect-skills/ethics-skills-in-it-architecture/#comments Sat, 17 Jan 2009 16:13:51 +0000 superfli http://enterprisearchitecturecoach.com/?p=256 A repost from The Architect Abstract

I’ve been away building and authoring courses, so writing has gone into something other than frivolous blurbs. Just came back from an evening with a speaker on ethics – it was supposed to have something to do with Ethics in IT and although that’s not what it was about,

]]> http://architectbootcamp.com/architect-skills/ethics-skills-in-it-architecture/feed/ 0 Architecture Skills and Competencies http://architectbootcamp.com/architect-skills/architecture-skills-and-competencies/ http://architectbootcamp.com/architect-skills/architecture-skills-and-competencies/#comments Sat, 17 Jan 2009 16:09:49 +0000 superfli http://enterprisearchitecturecoach.com/?p=253 An architect’s skills is a very blended list.  The architect must have several key skills that are beyond their technical skills.  Each specific architect will come with a bank of skills that they gleaned from being involved in the technology application or data areas of their previous experience within information technology.

]]> http://architectbootcamp.com/architect-skills/architecture-skills-and-competencies/feed/ 0 Standarize Architecture Documents http://architectbootcamp.com/architect-skills/standarize-architecture-documents/ http://architectbootcamp.com/architect-skills/standarize-architecture-documents/#comments Fri, 31 Oct 2008 16:17:41 +0000 superfli http://enterprisearchitecturecoach.com/?p=261 Recently I attended a meeting for a client who has a large strategic planning initiative underway.  I am analyzing their findings and recommendations, and helping them pull together the real key items so that they can present it to executives and actually have them act on the recommendations they put forward.  Great concept!

One problem with the project is that they set no standard for each group to follow when documenting their findings. This led to paying a technical writer several times over to move information around and reformat several times, not to
mention the costly meetings of the groups over and over again to rehash the formats.
Standardizing documents is not my intent for this article.  It’s to share some experience and knowledge for building standards and deciding what should get standardized.  An organization can often lack in standards for both technology and business processes – we’ve all seen those organizations.  Very often they are disorganized and generally unprofitable.  This supports an environment of complexity, as standards help to ensure those who require the structure can build and grow at an appropriate pace.
Other organizations can have so many standards, especially in process, that they are hamstrung to do anything that doesn’t fit the mold.  Take your friendly neighborhood utility for an example.  Ever try to figure out who to call in such a large organization, or ask for information on something that isn’t their every day common situation?
They almost seem unable to think or speak to what the potential solution might be because they are so used to looking it up in their policy books. So what kinds of standards should an architect strive to gather and maintain?  Think about your four pillars of the standard enterprise architecture – business, information, application and technology.  The last three are the three most common areas to create standards for, while the first is the most common to set up processes for.  Within each of these standards, the architect should strive to have standards around modeling, artifacts, documentation, and source
control.
To drill down further, the data should have data attribute type and naming standards, as well as storage standards.  Database structure and design is another area which should be standardized.  Processes should be created around back
up and recovery, upgrades and installations.  Ad hoc data fixes should always be scripted, and standards should
exist about how they are written and where they are stored after they are executed.
Applications should have a large focus on standards, the biggest of which should start with a standard application framework.  Following this should be button, navigation and menu standards, pattern usage and development standards,
error message and testing standards, as well as usage, and user interface standards.  This list is definitely not
exhaustive, but it’s a great start.  Naming standards are always a party favorite – why not throw them in as well?
Technology is probably the most intensive area for standards and definitely most easy to document.  Many technology
standards are inclusive within the tool or technology being used. These are typically the most stringent and necessary
as the application and information staff are very dependent on knowing them in order to develop and maintain systems, as
well as to actually make these run and work.
With all of these standards, there is a possibility that too many of them can be created.  Doing this will cause an incredible amount of effort to maintain them, and can cause an environment of rigidity.  It is good that there are enough standards to create an environment of creative tension, allowing new ones to be embraced through technology advancement and governance.  This would be the ultimate level to aspire towards, but it is very difficult to keep this under control, while not going to far, and continuing to go far enough.
]]> http://architectbootcamp.com/architect-skills/standarize-architecture-documents/feed/ 0 Modeling 101 http://architectbootcamp.com/architect-skills/modeling-101/ http://architectbootcamp.com/architect-skills/modeling-101/#comments Fri, 31 Oct 2008 16:16:11 +0000 superfli http://enterprisearchitecturecoach.com/?p=259 This week let’s discuss Architecture with respect to the models required to build a system from the ground up.  I won’t get into the details about how these models are built, just which ones you really really need.

In another article, we’ll talk about the benefits of modeling.  As you may be well aware, a picture is definitely worth more than 1,000 words.  I make my living either creating models or mentoring those who do, or developing strategies and documentation around the models those should create.  So basically – I’m biased.

I had a very pleasant interaction this week with an attendee of one of my speeches/seminars at the Enterprise Architectures conference asking “what else do I need to complete this architecture”.  It’s one of the most common things I am asked.

At the end of the day, what you need is very specific to your situation.   A model is just a mode of communication.  Each time we build a system or prepare to maintain one, the business issue, driver or problem is different, so each time we should evaluate if our normal model of operation is enough – do we need new models, or even a better question – is there a better model to be used to get my point across?

I’ve often try to help folks on a project for a client who are likely never going to get out of the old world of flowcharts and cutting & pasting old mainframe code into word documents and adding a bit of pseudo-code and calling it a Use Case.  It doesn’t help when they ask “when do I need an Activity Diagram, or a Use Case Diagram” and I answer “it depends”.

Don’t start saying I’m the same as the rest of the consultants – I actually follow up with some questions about what they are trying to do and what they are trying to say.   In a nutsell, each system architecture needs the minimum to survive:

- A High Level Business Use Case Diagram (includes use cases that map at the domain level, rather than at the specific system activity level)

- A Class Diagram focusing on Entity Classes (your Logical Model)

- A Physical Model depicting the database plans

- Some type of GUI prototype or model

- Some Architecture documentation that describes non-functional requirements, navigation within the system, technical architecture and security architecture (these will include these models)

Bear in mind – these are the minimum that should be included.  In addition, when one gets really confused and delayed in writing the use cases, use case diagrams, collaboration, sequence, state and activity diagrams should be used.  Deployment diagrams are handy when it is complex.

These diagrams are time-consuming to create, and should be used especially when a new pattern or new components are being introduced.  Again – it’s supposed to be common sense, and my sympathies go out to you if you are burdened by an application manager or architecture manager who has a checklist to be completed with each project, irrespective of the tasks at hand.

Sidenote:  Don’t forget that updating an old diagram is the way to go on any maintenance tasks.  Old models are great to use as a base, and if you have them, even if paper-based, dust them off and get going.

]]> http://architectbootcamp.com/architect-skills/modeling-101/feed/ 0