Technical Architecture Development
HLN Consulting, LLC specialize in information systems planning, consulting and research projects focusing on the public health and health care markets. HLN retains a cadre of experienced content consultants and information technology professionals able to bring independent expertise and judgement to bear on your organization or project. They work collaboratively with agencies and their stakeholders to balance technology, organization/politics, and resource allocation in a successful effort.
Project assessment is a key component of this work. A number of strategies are used to help assess projects for effective startup or continuation:
- Structured site visits to understand your unique environment, and exchange knowledge with your project stakeholders.
- Structured methodologies to help analyze your circumstances without “reinventing the wheel.”
- Facilitated meetings to help you participate with your stakeholders without the burden of conducting group sessions.
- Technology-assisted collaboration strategies to help you work more effectively with your stakeholders.
- Industry information from technology advisors such as the Gartner Group.
- Detailed reports delivered either on a customized, password-protected website or via hard copy.
One of the main tools we have available to assist technical projects in getting back on track is a structured methodology first developed at the University of Pennsylvania in conjunction with James Martin and Company.
A technical architecture is the process for developing a blueprint for making choices about hardware, software and communications procurement for an organization. From it flow standards, specific purchase recommendations, and other investment decisions regarding technology and its use in the organization.
What are some of a technical architecture’s attributes?
- It’s as much a process as a product.
- The crucial objective is to improve the performance of the organization.
- It is not a platform from which to preach a certain methodology or justify a predetermined technical direction.
- It is not technical mumbo-jumbo: it must speak to business people as well as to technical people.
How do we choose a Technical Architecture?
Four factors, when considered together, form the basis of research necessary to develop a technical architecture:
- Business Requirements: A technical architecture must help fulfill the business requirements of the processes it supports. Requirements are clearly articulated and prioritized. Assumptions are be made clear, as well as the risks of doing (or not doing) certain activities.
- Information Technology “Principles”: It is helpful to articulate a set of basic, but shared, beliefs about information technology and its role in the organization. These beliefs are negotiated among all relevant stakeholders, and are stable enough once ratified to form the basis for moving ahead and selecting an architecture.
- Understanding of current (de facto) architecture: Before an organization can move forward, it must understand where it has been and where it is currently situated in terms of its technology choices. Often, this step involves careful documentation of current systems and infrastructure in a way that has never been done in the organization.
- Relevant Industry/Technology trends: An organization needs to spend a portion of time evaluating new technologies, and studying new products and strategies emerging on the horizon. While few organizations can devote extensive resources to such industry examination, some level of technology tracking is always necessary.
The information from these four factors is combined to build a technical architecture description. Given a fixed set of resources, a variety of tradeoffs will have to be made as a project makes decisions about its architectural choices.