Why We Call Ourselves Architects

Business Process Architect and Requirements Architect are the terms we use for the roles commonly known as business analyst or systems analyst. We've chosen to put "architect" in the names because we believe that these roles should function in much the same way as an architect who works with a client on a building project. By using an architect you get someone who has experience and can suggest alternatives for you to select from; someone who can model the solution in terms that you understand; and someone who can interpret and translate your needs to the builders. The blueprints an architect creates are invaluable months and years later when you need to redesign, enhance or even tear down what's been built.

The same principle applies to business process improvement and to developing requirements for change. This quote from a Chief Technology Officer perhaps says it best:

"Users have trouble expressing their needs and desires in a way that the technologist can understand. There must be someone in the middle to interpret what the user is saying and translate it to IT."

We as architects are experts in eliciting information and in capturing knowledge in models that represent all the necessary perspectives and in words that are crystal clear. Because you, the business owner (the user), work with us, you can review the work intelligently and be confident that it represents what you really want. Those same deliverables can be used to communicate with those who will realize the change - developers, testers, and implementers. We can become the "someone in the middle" - the architects - for your projects.

• Facilitating sessions with business sponsors and subject matter experts.

• Meeting project objectives by managing, directing, leading, controlling, monitoring, communicating, and reporting business requirements to project managers assigned to the project.

• Measuring requirements and process models against project plans and corporate goals.

• Ensuring all requirement-related issues are resolved and key decisions are made in a timely manner.

• Providing leadership to the project team as it relates to Process Modeling or Requirements gathering.

• Developing an approach to address a business problem

• Communicating requirements to IT and managing change during design and development.

• Conducting follow-up or requirements reviews to ensure objectives were met.

• Promoting project artifacts to build an enterprise architecture.