Use Business Architecture to be Successful in Emerging Markets

In the Gartner article CEO Survey 2012: Use Enterprise Business Architecture to Expand Into New Markets and Geographies, it discusses how enterprise architects can better define how the business integrates with IT in order for the organization to be successful in emerging markets. The article recommends the following:

  • Develop a future-state anchor model to communicate the future state of the business and inform business architecture.
  • Review and update the business architecture components to understand the impact of future expansion efforts.
  • Include people, financial aspects, organization and business process dimensions in business architecture.
  • Leverage business capability modeling to understand the higher-level concerns before delving into business process modeling.
  • Model the business operations of IT and the business.
  • Leverage the enterprise context to guide the development of the future-state business architecture.
  • Focus on the future-state business architecture and only enough of the current state to understand the gaps.

The article also states that one of the biggest challenges for enterprise architects is that most of the time they report to someone in the organization who is in IT. In order to assist with being successful in emerging markets, enterprise architects need to focus more on business architecture and the business context by defining multiple aspects of business viewpoint stakeholders, financial funding and profitability, organization, and process dimensions.

Best Practices for Developing Enterprise Context

The Gartner article “EA Must Include Defining Your Enterprise Context” provides best practices for developing the enterprise context. This is something my organization has struggled to define. The best practices are as follows:

  • Collaborate With Business and IT Leaders
  • Identify Trends and Business Strategy
  • Develop Anchor Models
  • Evolve the Enterprise Context
  • Document Enterprise Context Efforts

My organization approaches business strategy from a gut feeling or by word of mouth from various connections leadership makes. Very little is documentation is done to identify environment and technology trends. I attempted to document trends externally and internally to the organization however it turned into venting about needs to get fixed internally. As a result, I created a process in which individuals can submit new ideas and enhancements to various systems in the organization.

In order for my organization to grow and to be thinking about leveraging enterprise architecture, it needs to think more about the enterprise context. Market data, project, and customer feedback need to be used to identify trends and create business strategies. Over the next few months, at our monthly leadership meeting, I plan on introduce various methodologies to help identify our trends and come up with a better business strategy. Our company is in a fast pace industry where we need to gain knowledge quickly and be able to adapt to the industry.

Using Business Canvas Models to Define Business Services

I was reading the Forrester article Identify Essential Methods For Your Business Architecture Program and how the business canvas model can be used to describe the business from a high level. An example of the business canvas model was in the areas of

  • Key partnerships
  • Key activities
  • Key resources
  • Value proposition
  • Customer relationships
  • Channels
  • Customer segments
  • Cost structure
  • Revenue streams

Once defined, key capabilities can be developed to develop the purpose of the business. From here by leveraging the business canvas model and the capability map, business services can be defined to establish service level agreements such as cost, quality, speed, capacity, geographic reach, and timeliness. Business architects can then use these business services to identify which processes implement the services by linking processes to the capabilities.

In my day to day working with clients in implementing their configuration management database, they often defer to my organization to identify their business services. We often define business services in three different categories. The first being the business service itself which I’ve already discussed. The second being technology services which can make up one or more business services. Lastly, the third type is supporting services which can be a technology service or business service that supports an overarching business service. Most clients only define their technology and business services.

The challenge with implementing business services in our client projects is that the business is never involved. Instead business services are defined by IT so it doesn’t necessarily define the overarching business services. In 2018, one of my goals as part of the leadership team in my organization is to determine how we can have conversations with the business to help define their business architecture and their business services.

Chief Information Security Officer: Often Needed but Not Always in Place

I was reading the sample job description for Chief Information Security Officer and realized that not many of my organization’s clients has such a role defined. Clients due have a security team but the manager of this team is typically a director or vice president of technology.

Typically, these teams are focused on application or infrastructure level security as opposed to incorporating security in the strategy of the organization. These teams appear to be frustrated with the decisions management makes because they are given an application or technology and then told to make sure security policies are implemented. This poses many challenges if the security team doesn’t know the capabilities of the technology as well as the purpose of implementing it.

As a consultant in a smaller IT consultant firm, we typically don’t have conversations around future state architecture or organizational changes. If we were to be in those conversations, a chief information security office or at least someone in a strategic position with a security focus would be highly recommended. Ideally, my organization could offer a service in place of that position to create a new line of business.

Securing Scalable Micro Services

I was just reading this article the other day about how organizations are going from a security fortress model to a micro service model. In the article it states that traditional IT build a wall around their infrastructure and have one drawbridge (gateway) into their network. This always for full control however it poses a challenge with flexibility in the current era.

For scalability, organizations want microservices or small portable applications that can connect with the internet of things. As the article states, Netflix and Amazon Web Services has perfected this which has allowed for their services to be interchangeable with devices and scalable from a resource perspective.

The article goes on by saying there is a new security model that allows for this type of environment and it’s called “Software Defined Perimeter”. From my understanding of the article, the security team does not care from which device the connection is coming from. Instead, if a user is able to access the software and provide valid credentials then they are authorized to use the software on that particular device. In terms of micro services, this means that the developers need to make sure the software is portable and the proven security controls can be portable with the software.


Fulton III, Scott. 2017, December 6th. Searching for the perimeter in cloud security: From microservices to chaos. Retrieve from

When is security control too much?

I was working on an 8 month contract with a manufacturing company that specialized in paper products such as paper towels, feminine products, and other household items such as bottled water. At the start of the project, we knew that the security team created a culture of paranoia and needing to control all information and applications. At the kickoff meeting, my team was told that we will not have access to the production environment and if we do then we need to share our screen in a virtual meeting and of their employees will need to watch what we are doing. We were also told that the same rules will apply to their testing environment. For the development environment, the culture they created was at the forefront.

The security team had created a policy that any user information other than their network id was to be enforced in order to remain HIPAA compliant. We consistently explain what the HIPAA law was, what information is governed in the law, and how it does not apply to active directory information. Nevertheless, we had to cleanse all user data so that no personal identification was revealed in the development environment.

The security team also had created a policy that any asset information, related IT hardware, needed to be removed from the development environment. Ironically, one of our deliverables was configuration management and asset management which relies on this data to govern business logic in the application. As you can imagine, this made completing this deliverable almost impossible.

The security team also didn’t stop there. For their help desk tickets (Incident tickets), tickets related to root cause analysis (Problem tickets), and configuration of hardware changes (Change Request tickets), needed to have extreme business logic developed in order to align with their security practices. Any mentioning of a IT hardware’s network name, IP address, or port number needed to be removed from the ticket and added to a separate database for employees with the right access to look at. The challenge though is that the individuals assigned to those tickets also needed that information to do their job. Those individuals were most of contractors or external vendors. As a comprise, an approval process was put in place so that an employee of the organization can review the ticket, the data in the separate database, and who was assigned to the ticket. If everything was aligned with security’s policies, then they employee could approve the ticket to be worked and then the associated ticket would be completed.

Based on the security policies of the organization, we had to do a change request on the project that equaled almost double the amount of the original contract due to the length of time needed to overcome the challenges, take into account defects related to developing the deliverable without all the information, and the number of meetings needed to gather extra requirements. As a result, our change request was approved and we completed our deliverables.

A few weeks after our project was completed, we met with the customer to see how the adoption of the new applications was working out. We weren’t surprised that the customer said that their employees and contractors hated working in system and wanted to go back to their old system because the workarounds were much simpler. We kindly provided an explanation and offered to help change their system to make it right at a lower cost. Unfortunately, the security team disagreed with any changes and so nothing was done to assist with the adoption of the new system.

For some reason, the customer saw the lack of adoption as being the vendor’s fault aka my project team’s fault. Instead of putting blame on the security team for putting extreme policies in place, we became the scapegoat. As a result, we terminated our relationship with this customer. As of now, it appears that they are abandoning the new system we put in place and are going back to their old SharePoint processes which as you can imagine is wasteful spending in an organization.

The lesson I’ve learned from this project is there’s a fine line with security in creating policies. I do agree that the security team should create policies that protect an organization’s intellectual property and items that may cause a security breach. However, if there are enough controls in place to prevent a security breach and developers need the data in order to build controls and business logic to make the security team’s job easier then they should not be the road black in the development process. Also, if they do not have a clear understanding of rules and regulations and proper evidence is given to them that they are incorrect about their assumptions, then there needs to be a governing body that can overrule their policies and enforce them to change it. In the case of my client, this governing body was the owners of the manufacturing company. The organization chart of the customer was rather odd. The CIO reported to the CFO and the security lived outside of IT under the direction of ownership.

It’s Not Easy Starting a Managed Service Offering

The Gartner article “Key Considerations When Thinking About Insourcing or Changing IT Service Providers” was an interesting read because my organization has been trying to start a new line of business in managed services. The idea is to have three different service offerings for a managed service: Bronze, Silver, Gold. The bronze service offering allows the client to have a finite number of hours per week to leverage a pool of resources for defects and enhancements. The silver service offering assigns a ServiceNow subject matter expert to the client and can be utilized for development, design, and road mapping of their platform. The gold service offering is a complete outsource of their ServiceNow help desk team. All defects and enhancements would be routed to a dedicated team in my organization.

The initiative has started a little over a year ago with a RFP with a luxury bag manufacturer. The client worked with us for many years and has a sound understanding of our services and quality of our deliverables. We were very confident that we were going to win the contract however this was not the case. They saw too much risk with being the first client for our managed service offering. From an evaluation standpoint, this makes sense especially after reading the Gartner article previously mentioned.

The article mentions the common factors that drive the decision: Cost, Control, Change, Contract, Alignment, and Frustration with service quality or vendor relationship. The common factors that was driving the need to outsource the services was the following:

Change: The client was pursuing various acquisitions and did not want to invest more money into the IT department.

Cost: Outsourcing the help desk will be much cheaper than keeping employees on staff.

Alignment: There were too many vendors and contractors work on the ServiceNow platform. Their goal was to work with one vendor for not only outsourcing the help desk department but also for project work, defect remediation, and development of enhancements.

After being notified that we lost the RFP, we reached out to our contact within the organization and asked for feedback. Much to our surprise, the quality that we were known for was not a metric in the decision process. The client was looking for a cheap alternative, that has a reliable and proven process, and is flexible to make adjustments when needed. Unfortunately, our proposal was different from this. The owner of my organization stressed that they would be the first client so we would align with them from a cost perspective in order for us to get the process correct. Our costs were much higher because our organization is entirely U.S. based. Our competitors outsource their developers to India which makes them much cheaper from a vendor perspective.

One year later, we’re still are trying to perfect the delivery of our proposal. I plan on sharing what I learned from this Gartner article so that our service delivery manager can prepare a proposal that addresses the common factors in deciding to outsource and to answer some of the questions when determining outsourcing is a viable option.

Huntly, Helen. (2013, June 25). Key Considerations When Thinking About Insourcing or Changing IT Service Providers. (ID: G00249310). Retrieved from Gartner database.

Technology Evaluation From a Small IT Consulting Business Perspective

One challenge my organization has without technology architecture is with the services we offer our client. We have two types of technology that we must evaluate internal technology and technology tied to the services we offer. New technology is brought into my organization based on 4 different criteria which are: client’s standard for project delivery, project delivery improvements, technology related to a new service/line of business, or an issue or threat has been identified.

The first way technology is introduced into my organization is the standards a client requires for their projects. For example, for one project we had to design a web interface for their self-service portal. We initially used photoshop to provide mockups however the client’s graphics department ironically did not use this for initial web designing. Instead, they used an application called Balsamiq. We ended up purchasing a license in order to use the application and keep the project moving along.

The second way technology is introduced into my organization is an identified opportunity to improve project delivery. Our profitability of projects is dependent upon how quickly we can complete projects without decreasing the amount we charge for a deliverable. In order to do this, we have to create reusable/templated deliverables and/or use technologies to improve our processes. This type of technology is typically not sought after from a research perspective. Usually other efforts identify a use case or an online article one of my employees have read and briefly propose the use case. The rule of thumb in my organization when it comes to using technology for project work is if you think it’s a good idea then pilot it in your next project and see if it in improves our delivery process. Balsamiq was mentioned previously as a technology used with a client project due to their application standards. We saw this application as an opportunity to improve how we deliver our self-service portal deliverable. After that particular project, we began using it for other portal projects and found it as an opportunity to increase customer satisfaction. Now it has become a standard in my organization.

The third way technology is introduced into my organization is related to a new service or line of business. The leadership steering committee typically decides on a new service offering or a line of business that we want to pursue. In this scenario, it is up to the delivery team to identify the technologies needed to support the service or line of business. There’s also another scenario where lines of businesses and new services are driven vertically from employees. In my opinion, I find this to be the biggest opportunity to drive innovation and to grow the company however, there is a major roadblock. Ironically, our sales team is not very technically knowledgeable. ServiceNow implementations are our main line of business and is very easy to talk about to a non-technical individual. When a new idea is driven vertically, the first question that is asked by our sales team, who is also run by our CEO, is “I don’t know how to sell that”. The business need and/or industry trend is typically used as the answer to the question. If the CEO and sales team doesn’t understand, then the idea is squashed and no further research is done. The delivery team finds this to be one of the most frustrating situations. Lately, I’ve been trying to assist my team members with developing business cases in order to present their ideas. One result of this is our current pursuit is to start a cyber security line of business.

The fourth way technology is introduced into my organization is the result of an issue or threat internally or externally to my organization. For example, as an IT consulting company that works in the cloud, access to the internet is crucial to the organization. Previously, our Comcast cable internet’s downtime was increasing by the week. We had no internet backup so we were “dead in the water” sort of speak and could not work on our deliverables or host meetings with our clients. We then have to rush home to use our non-work internet which raises security concerns. As a result, we established a internet backup connection using a lower priced smaller bandwidth connection using fiber. When our main internet connection goes down, we no longer need to panic and can continue with business as usual.

Our 2018 goal is to become more standardized so our processes and reporting structures are scalable as we grow as an organization. One of the biggest areas of improvement is documentation created from projects and becoming more efficient with creating statements of work. We are currently evaluating Office 365 and understanding all of it’s capabilities. The other item I’ll be personally working on is assisting with technology proposals so that the sales team no longer becomes the gatekeeper of pursuing technologies for new services and lines of business. We need to better present the technology from a client’s business need perspective as opposed to a “next great technology” perspective.

Virtualization Is An Internal and External Frustration

The topic in this lesson is Technical Architecture and touches a little bit on virtualization. Virtualizatio has becoming a very hot topic internally at my organization as well as conversations with clients. Clients try to save money and resources by creating virtual workstations for employees so that they can bring their own device. They also use a similar approach to contractors and consultants to keep their network and data secure. They also do the same with servers as well. In this post I’m going to discuss a few observations and challenges as it seems like clients are letting technology drive their business.

Virtual workstations are definitely the biggest risk to our projects. When clients have a policy that consultants must use virtual computers in order to develop and share documents, it is expected that the device will be very slow and there will be many access issues. Client’s virtualization teams will typically provision workstations with the least amount of resources and application/network access. It can take up to two weeks for a virtualization team to add more resources to the image or receive justification on why my project team needs more access. As a result, we typically do a change request to the project to either extend the project or add additional hours. As you can imagine, clients do not like tapping into their budget for more money. Sometimes while negotiations are taking place, the virtualization teams increase resources they want to see proof that there are issues. In one particular case, the virtualization team increase resources while we were justifying a need for a change request then immediate reduce resources once we identified there was no more issues with the virtual workstation.

The biggest challenge internally for clients is the inability to control when virtual servers are created. It is always best practice to have a change management ticket before placing any type of device on an organization’s network for auditing and security purposes. Since provisioning a server takes less time than putting in a change take, teams try to find entering one in the first place. As a result, there’s no justification on why server and virtual licenses are increasing or and checks and balances that the individual selected the correct virtual image to grant appropriate access.

As an IT consulting company, we identified this issue as well as our software vendor we have partnered with. They have created integrations with populate virtualization software such as Citrix and VMware. The idea is that only super users can manually spin up a virtual server and anyone else has to use to put in a request for service and a change management ticket. Once approved and within the change window, the software we implement will use web services to provision a new server and validate the correct virtual image was used.

From our observation, this issue is only going to get worse and the knowledge gap with these virtualization software is going to get broader and more complicating. There is an opportunity for us to become experts to help our clients however there are other higher priorities internally.

Information Architects Role in Enterprise Architecture

I found the article Information Architecture 101: A crash course for the enterprise architect by IBM provides a nice synopsis of what information architecture is and what is the role of the information architect. The approach to this article is to assume the reader is an enterprise architect so it gives more insight on how you will interact with this individual and how they will play a larger part in projects.

It states that the information architect will entirely focused in three areas

  1. Users of the information – The individual is concerned with knowing everything and everything about the users. This can range from knowing the user’s role in the organization, work ethic, location, or the even the type of format is the easiest for them to understand.
  2. The information itself – The individual needs to take a top down and bottom up approach in order to organize, label, and group information. The individual will need to understand the entire information scope and the granular details of each data attribute.
  3. The business or organization – Bottom line the individual needs to understand the needs of the business and not necessarily the needs of the technology architecture. A good understanding of the business goals will make the information architecture successful.

The author then moves to what information architects do which can be labeled as ask, observe, learn, and iterate.


Ask explains the nature at which information architects ask questions. The tools involved require asking questions directly and indirectly. This can be done by either asking specific questions to users or perform an exercise with a group. Once the initial data is collected, a cluster analysis is performed. This analysis calculates the distance between two concepts. The result is a cluster graph that shows relationships between concepts. Survey is also another technique that is briefly mentioned under the ask label which coincides with asking specific questions at certain periods of time.


Observe is a technique to view data to day operations without being in the way or distracting the users. The goal is to “observe, record, and experience. The key point in this section is that “there is always a gap between what users tell you they do and what they really do”.


Learn is the idea that information architects need to do research. Research may entail understand information related to culture, language, colors, and layout differences just to name a few. Sometimes data isn’t fully realized yet about user interaction with a system or cultural or language differences require different presentation of information, or what types of labels allow for the best user experience.


The only way to continuously improve the information architecture is to repeat Ask, Observe, and Learn over and over again to gain more feedback and allow users to become more efficient and systems to become more effective.

Business users expect systems and technology to already know what they want and when they want it. In order for to ensure infrastructure and applications support the business needs, information architects must constantly review changes, gather data through asking questions directly and indirectly, observe users’ day to day operation, and learn how to improve systems through researching.

Skip to toolbar