jump to navigation

Business operational architect February 6, 2012

Posted by Chris Eaton in architecture, Enterprise Architecture, methodology, methods, people, profession.
Tags: , ,
5 comments

funny how time flys…200+ days since i made a post. Hard to believe it!  t’has been a busy time

One idea I have become very interested in recently is the idea of a Business Operations Architect (better names may exist!).

Let me explain this role. I am very interested if this role exists in organisations already and what i might learn from them

My starting hypothesis is:

  • most architects are working on project delivery, architecting new solutions or upgrades to existing ones. Typically they introduce new functionality to end users (business, application or functional architect)
  • some architects design infrastructure (technical or infrastructure architect)
  • some architects are working on Enterprise Architecture; they plan the future IT landscape of applications and infrastructure

No architects are looking at current applications, their functionality, infrastructure, incidints, problems and supporting environment such as monitoring, capacity, performance, etc .

Therefore: a new role is needed: the Business Operations Architects: they ask and answer the following questions:

  • Are users happy with the functionality? what needs to change to improve user experience and function?
  • What incidents have happened, how can they be prevented in future?
  • What problems exist in the current solution and how can we solve them with future releases?
  • Is the supporting operational infrastructure fit for purpose (monitoring, alerting, hardware type/age, software age/support arrangements and if not, what changes are necessary?

They would also play an assist role:

  • are new solutions fit for purpose; functionally and operationally? they would lead or participate in architecture reviews
  • ensure changes are accurately reflected to documentation such as system scope diagrams, interface specifications, architecture diagrams – these often are out of date relating to atrophy of design
  • provide expertise to support incidents and help restore service

is this a good idea, is anyone performing this role, does anyone have a better name for it!

thanks

Chris

Architecture method template work products / artefacts March 24, 2009

Posted by Chris Eaton in architecture, architecture method, artitecture, IT Architecture, methodology, methods, total lifecycle thinking.
Tags: , , , , , , , , , , , , , , , , , , , , , , , , ,
1 comment so far

Following on from previous posts below are links to all the work products in the artITecture architecture method. The work products contain suggested formats and advice for completing them. The templates are intended to be just that; templates, customiseable to your own use.

Work Product Name Download Link
Architecture Decisions Link
Architecture Overview Diagrams Link
Architecture Risk and Mitigation Plan Link
Architecture Scope and Context Link
Change Cases Link
Component Architecture Link
Data Architecture Link
Decision Model Link
Functional Requirements Link
Infrastructure Architecture Link
Integration Architecture Link
Non Functional Requirements Link
Technology Assessment Link

Architecting for the complete systems lifecycle March 5, 2009

Posted by Chris Eaton in architecture, architecture method, artitecture, IT Architecture, methodology, methods, total lifecycle thinking.
Tags: , , , , , , , , , , , , ,
add a comment

Architecture is often focused on the implementation of a successful solution and it is easy to understand that the immediate concern of an architect and the project itself is to successfully go live.

I suspect that few (perhaps even zero!) architects or indeed project managers are incented on the long term success of the implementation and success of a solution over a number of years. The following diagram is my own version of the waterfall model.

systems lifecycle

The model looks pretty close to any other version of the waterfall model, but includes linkage to IT Strategy and Enterprise Architecture, and at the tail end to Service Delivery, Service Management and the eventual decommission of the system. The architectural thinking should included all these phases. The later end is often forgotten with little consideration to how Service Delivery/Service Management will run, diagnose, recover and ensure the solution meets the required service levels. This is often referred to the IT-IT Gap, where the implementation project does not talk to the service delivery/service management world, and at handover from project to run… there are issues which could have been avoided by total life cycle thinking.

The artITechiture solution architecture method makes explicit reference to each phase in the recommended documentation, the documentation should be considered both a formal document but also a prompt for thinking about all aspects of the systems life-cycle.

looking for mentees July 18, 2008

Posted by Chris Eaton in communications, IT Architecture, mentoring, people, Uncategorized.
Tags: , , , , , , , , , , , , , ,
1 comment so far

I am looking to mentor people in IT architecture. Part of the Open Group IT Architect Certification (ITAC) requirements is ‘giveback’ to the profession and mentoring is one of the most important. I have experience as an application, integration and enterprise architect with particular technology experience in SOA and most IBM software

Mentoring is not just about technology, it is also about careers, coaching and soft skills…

I also have quite a few certifications which i can help with too, including TOGAF, ITAC, Sun Enterprise Architect and Project Management Professional

I am also a dab hand at reworking CVs and Resumes…

If you are interested in discussing mentoring please contact me at gruffoot@gmail.com

IBM EA method and IT Inventories June 27, 2008

Posted by Chris Eaton in EA, IT Architecture, methodology, methods.
Tags: , , , , ,
2 comments

I have been thinking some more on the difference between the IBM Enterprise Architecture method and TOGAF. In the IBM EA method there is an strong emphasis on maintaining an IT Inventory. This seems oddly absent from TOGAF altogether. An IT inventory maintains a record of what applications you have, what technology they run on, the functions they perform and often financial data is attached to them too.

Understanding what applications and IT you have today in some form is crucial to making decisions for many reasons – to understand total costs, to enable you to identify and sunset applications which perform duplicate function, to have a total picture of what applications you have in the first place, to identify other IT rationalisations like server consolidation.

In IBM internally the company wide application inventory is also used to track all IT projects both in flight to deliver something an upgrade to an existing application and projects which will deliver something entirely new. This is really the centerpiece to tracking projects and the current application inventory and scheduled upgrades it takes a more holistic view than just what is live now, you can also extrapolate what the application looked like in the past, and because it tracks in flight projects you can see what the inventory will look like in the future if all the project deliver on time.

I wonder why TOGAF has a gap here it is such a powerful tool for analysis and communications. The IBM solution is custom built, are there any software applications out there to maintain an IT inventory?