Introducing Data Driven Decisions in a Startup Environment

I work for an IT consulting company that has roughly 50 employees. Day to day operations are informal and decisions are typically ad hoc. Since I became manager of our delivery team two years ago as well as joined the leadership team, I tried to find ways to capture data points and use data as evidence for my ideas or reasons for change.

In a startup company of only 5 years, there’s not many data points to drive decisions. Individuals are also resistant to change, fear of changing culture, and have the mindset that the organization isn’t large enough for structured processes. There’s also a sense of paranoia of “big brother” when you ask for more information to be entered on a user interface or rumors spread of reporting on what was people have entered in the past.

From a management and leadership team perspective, decisions were being made through “gut feeling”, opinions of employees, and direction from vendors. There was a sense that the organization kept reinventing the wheel sort of speak instead of improving on key processes and using data to understand weaknesses.

In order to find a starting point, I started asking very specific questions such as: What is our cost for each deliverable of a project?, How much time are being spent in meetings as opposed to working on our deliverables?, or even simpler how do we know who is working from home today?. These questions created a lot of debates but in the end, it created a conversation.

For simple data points like time being spent in meetings and our costs per deliverable, I proposed some changes to our work tracking application. The application has records for information about the project, releases of application development, and time tracking. In order to be very specific on when I would like to capture the data points, I developed a high-level process flow diagram using Visio. It helped me understand when records are created and who is responsible for entering the information. From this view of the process, I was able to better understand the information flow from one activity to another in the process and identify where my data points will be entered.

At the project level, I captured a list of all deliverables for the particular effort. For application releases, I captures all deliverables tied to that release. Releases are then tied to work management and time card records where specific deliverables can be identified. For time card, we leveraged a category field in order to classify generically what the time card represented. From a conversational perspective to prevent the “big brother is watching you” conversations from happening, I discussed with the delivery teams that deliverable information will be automated based on how we set up the system and the extra time card data point is a necessity to help them. Up to this point, employees would complain that they would have to stay late due to being in meetings all day. As a result of this conversation, a new opportunity surfaced.

With the capturing of when certain deliverables are worked on, we’ll able to do a trend analysis to see which deliverables are being purchased the most by customers. Since time cards are also on a per deliverable basis, we’ll able to calculate our overall costs for the project and over time understand how well or worse we are doing with our profit margins. The new opportunity that rose to the surface was the need to have more up front requirements gathering sessions and more of a hybrid waterfall/agile approach to projects. There was a significant time being spent on meetings and it was only because we would not have a formal requirements session up front. Instead we would meet once or twice a week to do small demos and ask for feedback. In a true agile environment, this works well but not from a services company where the company wants to grow and end projects on time.

After this realization that our delivery process was not as profitable, we revamped the process and statements of work to be more in our favor. The tracking of deliverable costs and time being spent helped us identify where more training is needed in order to anticipate demand with a particular deliverable. It also sparked more interest in what else we can learn from our own data points. As a result, we are ending 2017 with more revenue and more profit by using data to drive our decisions and bring to light issues that can’t be seen during the day to day operations.

ServiceNow Customers Lack Data Governance

After reading 5 Critical Success Factors for Initiating Master Data Management, I thought about my organization’s clients who we help bring their business and IT processes to the cloud leveraging the ServiceNow platform. One capability of ServiceNow is not only a blessing but also a curse is the simplistic nature of integrating with the platform. The platform can integrate with any system that can use REST, SOAP, send emails, export CSV or XML files, and can connect to databases using ODBC or JDBC connections. It’s a very powerful capability but it poses additional challenges related to data quality, data integrity, and ownership of data.

When a customer integrates many systems into ServiceNow that share the same data, it puts that set of data under a microscope because of how easy it is to report in the system. One report can identify misspellings, duplications, or misrepresentation of what the data represents. For example, location data is always a challenge with clients. Locations are used to represent where users, IT assets, facility assets, investment assets, and facility locations such as buildings, floors, and even offices. Typically, this data originates from systems that are controlled under different departments with no control of how it’s being entered.

After bring this unrealized issue is brought to the surface, the client has to make a choice. Do they decide to continue as is and “kick the can down the road” or address the data issues? Believe or not, clients would rather ignore the solution and finish the project than plan for fixing the issue in a second phase. I’ve been on roughly 10 to 15 projects with a few rather large organizations and only one client saw this as an issue they want to plan to address.

The client is a large luxury bag designer whose enterprise architect introduced me to the EA field. The project I was on was to integrate as many systems as they can with his current application portfolio. After identifying data inconsistencies, we had to shift focus into tracking which data came from which source. After we created a list of where data was coming from we identified where human error was a big factor into the data. The biggest violator was SAP and as mentioned as a typical issue, it was related to location data. The solution at the time was to create a process to change the data entry to being free form to a drop-down menu so only approved locations can be entered. However, this still left the challenge of what to do with the current data that is inaccurate.

The inaccuracy with the current data was something that was pushed off until a later date. It’s not something I agreed with but I documented the issue and moved on with the next integration. In my opinion, I saw an opportunity for automation. ServiceNow has the capability of orchestration. Orchestration is a capability that allows to run PowerShell scripts, web services, and database operations from the platform with the help of a java middleware application installed on the customer’s data center. Through this capability, business users/data stewards can update, add, or change the data in ServiceNow which will then update the source of the data.

With the correct security permissions set up and the right process in place, data governance can be used in ServiceNow which would make the platform a great master data management tool with such integration flexibility. The challenge is that clients don’t see data governance and master data management as a priority. We have an undocumented saying at my organizations that clients need help with helping themselves. I believe we can develop a business case for investing in data governance by providing metrics on how much time and money can be saved through improving data quality and the opportunities that can be derived from accurate data. My organization is always looking to start new lines of business, data governance may just be one of them starting with our ServiceNow customers.

Topic 2 – Most Organizations Lack Maturity

When reading Gartner’s ITScore for Application Organizations: Management of Architecture, it made me realize how many of my organization’s clients come to us with Level 1: Ad Hoc application architecture. Most of our clients don’t have well documented processes and don’t really know who does which tasks in a process. The surprising factor is IT leadership doesn’t want to spend the time and money to document the processes.

When we implement the ServiceNow platform with a client, we create repeatable processes without the client knowing. We assist with defining processes for various services and in ServiceNow’s workflow engine, we develop in a way that the workflows can be reused. Then when we have future conversations with the client, we use those workflows as suggested processes. For our long term contracted clients, it helps my organization stay efficient and increase our profit margins because the repeatable processes are more well accepted. When we implement a process for clients, we leave them with a Level 3: Defined application architecture. Typically, ServiceNow becomes the single source of record for most processes so documenting the processes and integration points often define the application architecture.

For our long-term clients, accepting ServiceNow as their single source of record helps with optimizing and automating the processes and application architecture. Our long-term clients often move towards Level 4: Optimized mature level within two years. ServiceNow’s ability to integrate with email, CSV/XML, databases, active directory, SOAP/REST web services, and be able to run PowerShell/SSH commands helps with automation and optimizing processes. The platform’s build in SLA engine helps with measuring how efficient the processes and services are which helps with continuous improvement.

For the smaller short-term clients, they spend more money reinventing the wheel sort of speak. They constantly are redefining their processes and rediscovering what they implemented in ServiceNow. Even though they have an individual who takes ownership of ServiceNow, they rarely have owners of the various applications on the platform. Internally, I’ve been pushing my organization to offer business analysts and business system analysts to help clients identify application architecture however the sales team has much difficulty having those conversations with clients.

Topic 2 – Common Integrations in With Application Architecture

As an IT professional for over 10 years, I am presented with various solutions and complexities related to integrating applications. It always starts with identifying the manual process. Typically, an employee has to manually copy data or transfer a file from one application to another. This scenario creates a lot of risk for the employee and the organization. The employee must remember to do the manual steps and execute accurately in order to prevent loss of data or the wrong data gets imported into the system. From an organizational standpoint, this can cause downtime in services, unhappy customers, data breaches, and in some cases money being transferred to the wrong individual.

The solution is always to replace the manual steps with an automated integration. The challenge with this solution is some legacy systems legally have to remain operational or it may be too costly to replace and don’t always have newer integration capabilities.  For example, a legacy system only has capabilities to export a comma-separated values (CSV) document to a folder on a server. A newer system may only have web services capabilities through SOAP or REST, which I’ll discuss more about below. This requires a middleware software to transform the CSV document into a REST message in order to send data from the legacy system to a newer application. Even though there are more costs up front, it saves an organization time and money eliminating manual steps.

Below is a list of integration technologies that can be used to eliminate manual steps and integrate various applications.

  • Flat file with SFTP/FTP – A flat file is typically used in the term of a comma separate values (CSV) or XML document. This file is transferred to an SFTP or FTP location in order for another system to pick up the file. When dealing with legacy systems, this solution is often used.
  • TCP connection – This type of integration I find not as common but still exists. I personally used it for credit card processing for a tuxedo rental company. The concept is as follows the sender application will establish a TCP connection on a certain port on another server. The recipient application will listen on that server for a connection on the given port. Once the connection is established, it will load/buffer the packets of data until the connection is closed. Then it will translate the data into meaningful information in order to be used in the application itself.
  • HTTP methods – This is another uncommon type of integration but sometimes can be found in the wild. HTTP methods tells a resource what type of action should take place. GET and POST methods are typically used for this type of integration. GET tells a resource to retrieve certain information based on parameters that are passed in the URL. POST tells a resource to store data that is passed as parameters in the URL. Both of these methods in my opinion were the foundation for SOAP and REST web services.
  • SOAP – SOAP is a form of web service that uses XML and the concept of schema. When a resource wants to send data to another resource, it must format the XML so that it matches the recipient’s schema. The schema is a blueprint defining the type of data and the format it should be structured in order to be considered safe to consume the XML. Based on my experience, this web service is no longer considered the standard. Many organizations and applications are moving towards REST web services because of how extensible and easier to trouble shoot it can be.
  • REST – REST uses HTTP to send XML, HTML, or JSON to send data. Due to the flexibility and easier maintenance, it has become the norm in web services. Much like HTTP methods, typically the REST message has the action within the text that is being sent. This becomes quite powerful since custom actions can be defined. Much like SOAP, as long as the right tags are used, there is really no limit on the amount of data that can be sent at one time.
  • EDI – EDI is another form of integration mostly used in an organization’s procurement and inventory management systems. It is considered an older technology and has been around for 30 plus years. The scope of EDI is beyond what I would like to discuss with this post but I can attempt to explain it with a few sentences. Previously we discussed SOAP. SOAP has an XML schema that restrict how XML is sent between two systems. EDI is very similar with standard structures however due to the standards, they are defined by transaction type. For example, if a manufacturer wants to order more raw materials from a vendor. There is a specific standard for this transaction. Same goes for submitting a purchase order to a vendor.
  • cXML – cXML is another form of integration that is similar to SOAP. There is a set of XML schemas that are used as templates. The only difference I’ve noticed is that is has an additional XML tags around the XML message. It’s not something I’ve implemented but was approached with solution when integrated procurement systems. Unfortunately, the system I was using to send the XML did not support cXML.
  • Direct Database Transactions – Definitely not the most ideal form of integration solutions but direct connections to databases is another way to integrate. This requires a database server to be exposed to the internet and JDBC or ODBC are typically used to run Insert, Update, or Delete queries into the database. Without full control over an application’s ability to prevent SQL injection, this solution is usually used inside a company’s local network where both the sender and receiver applications can be customized.

There’s definitely more integrations out there but I wanted to highlight all the types of integrations I’ve used in the past. Application architects have a difficult job with understanding an application’s capabilities and determining the correct solution for integrations. When the correct integration choice is made, automation can occur and time and money can be saved by the organization.

Topic 2 – The Idea of Business Services and How IT Can Help SOA

My company is an IT consulting firm which helps organizations bring their business processes to the cloud leveraging the ServiceNow platform and ITIL standards. In project engagements, we typically have to describe what a business service is and how it is use in IT service management.

ServiceNow defines a business service as the following “A business service is a set of interconnected applications and hosts which are configured to offer a service to the organization. Business service can be internal, like organization email system or customer-facing, like an organization web site.”. In the ServiceNow world, business services are part of the configuration management database which is a repository of applications, hardware such as network devices, servers, and appliances, and databases. By defining business services in the configuration management database, an organization will be able to understand what hardware and software make up that business service.

In the CIO article SOA Definition and Solutions, it defines a service as “software chunks, or components, constructed so that they can be easily linked with other software components”. By defining business services and leveraging the configuration management database, application architects can better plan and refine their service oriented architecture. This is possible because they are able to see which applications are tied to which critical business processes and be able to create reusable code based on similarity between processes.

The configuration management database is always a difficult deliverable to provide for clients. Typically, clients don’t have a well-defined business or technology architecture. ServiceNow offers an automation tool to build the configuration management database which is a good start in defining the infrastructure architecture. By defining an organization’s business services and tying them back to the infrastructure architecture in the configuration management database, it helps understand which applications are part of which business processes. This in turns enables service-oriented architecture planning and continuous improvement.

Throughout ServiceNow, business services are associated with help desk tickets, change management records, and project management. In a service oriented architecture world, this helps to track the integrity of code, the deployments of new services, and the planning for development of the services.

Topic 1 – Embracing Change for Future Growth

The Forbes article Change As Core Competency: Transforming The Role Of The Enterprise Architect and it kind of reflects how my role is shifting at my organization. Even though I’m a manager of consultants and developers, my role has been starting to shift towards and enterprise architect role. It’s tough to call it that but it’s definitely a watered down version of the role. As I’m taking EA classes and part of the leadership team at work, I feel the need to help formalizing strategy and truly understanding the vision as a team where we want our company to head. Every leadership meeting, I ask the same questions to the owners of my company “what area do you think we should focus on next”” or “is there a certain area of an industry such as, IT security, you want to focus on?”. The same answer is always given, I don’t know that’s why we’re relying on you guys the leadership team to define that.

In my organization, I can already foresee that traditional EA will not be successful. We don’t have a CIO or a CTO. Instead we have a leadership team with the owners (CEO and COO) providing the final say. For our internal purposes, I’m leveraging the knowledge of my coursework especially from EA 872 with relation to the Gartner toolkit for EA. I just recently met with each department to document trends that are happening internally and externally. I also did competitive analysis of large consulting firms to see what types of services they offer. Then I created a future state diagram to help with a starting point of where I believe my organization should be heading based on the trends and my competitor research.

I believe until my organization becomes a larger or until we offer an EA consulting service and need to devote more time to that, I’m going to be an individual who is an advocate for change by proposing future states. Contrary to the Forbes article, my organization can’t focus too much on the current state and making it better because the entire line of business is focused around one platform. In order to grow, we need to branch out and provide more business value by offering services that may not be large pain points at the surface but instead helps start the conversation to larger efforts. By proposing future states based on research, I believe it will help form a strategy for the leadership team and help the organization embrace change.

Topic 1 – Traditional IT Is Holding Back Transformation

As I was reading Cloud Computing: The Future of IT Application ArchitecturesI thought about my own work experience with cloud computing. My company is a partner of ServiceNow. We work with clients to implement the platform as a service. ServiceNow consists of many applications besides the Incident, Problem, and Change Management it is known for. There’s also Asset Management, Project Management, Facilities Management, Software Development Lifecycle, and Human Resource Management just to give you an idea of the broad range of applications.

As clients use ServiceNow to move their business to cloud, their initial strategy is that they want a solution that is scalable, mobile, and has the ability to integrate with various other platforms and in-house applications. From a CIO perspective, this sounds like a solution that will prepare a company to be as flexible as possible while increasing productivity and decreasing cost however post project analysis this is hardly the case.

Anytime myself or one of my employees begins a kickoff meeting for a project, this is the mindset the director of IT or CIO portrays to the project team. As the project begins to kick off with the most basic process of setting up a schedule to import users into the ServiceNow platform, traditional IT gets in the way. What I mean by traditional IT is the mindset that everything needs to be locked down from the outside world. Internally, only certain people can see certain data. From a process perspective, automation is not something the company does today so everyone needs to receive a task to push a button or enter some information.

In a cloud computing world, data is easily accessible and reportable across departments so there is not redundant data or processes. Business applications are accessed from mobile phones reducing the need to carry a computer. Emails are no longer sent out and instead are replaced with push notifications to devices or a messaging queue inside the tool. Since the platform is in the cloud, there’s no need to set up VPN or virtual lans between offices to share data or use on premise business applications. Most importantly since business applications can share data and cloud computing can integrate with other applications, there is opportunity for automation and orchestration of tasks. Unfortunately, the fear of traditional IT gets in the way of these capabilities.

When it comes to importing users through LDAP, typically with ServiceNow there’s an Windows service that sits inside a client’s network with communication initiated to the cloud from the service. In order to implement a normal solution like this, it requires nearly a week and a half discussion with a network team, active directory team, and security team in order to gain approval even though the IT directory and/or CIO approved at the kickoff meeting.

Another scenario that typically happens with financial institutions or some paranoid security teams is the need to lock down the cloud platform. This ranges from enforcing a VPN tunnel to the cloud servers to access the platform to restricting only select IP addresses to have access. In any case, this eliminates all mobile devices that management typically enjoys using to manage their teams and any flexibility of using the platform without overheard for distributed offices.

I don’t believe all businesses are 100% ready for cloud computing and cloud platforms. I believe there is still a fear of the unknown and the old mindset of traditional IT that are holding many companies back from reducing costs and gaining efficiency through cloud computing. Larger enterprises are embracing these newer technologies and see them as opportunities. However, small to medium businesses are still using old knowledge and experiences that are inhibiting growth and flexibility.

Topic 1 – The New Buzzword Blockchain

It seems like every day I’m reading a new article about how the technology behind Bitcoin is being re-purposed for a transactional business process.  I have a hard time understanding the concept/methodology so I’m using my first blog post to dig a little deeper.

What is blockchain?

According to IBM, blockchain is “a shared ledger for recording the history of transactions – that cannot be altered.” however what does that mean? As I was reading further, it is really peer to peer network. Every time a new transaction is generated between two parties, it is added to a block. The next block is added to the previous block creating the “chain”. Each member of the network has access rights. The blocks in the chain are permanent and cannot be deleted.

Business case

After reading through what blockchain is, I can understand why businesses especially financial institutions are highly interested in the technology. If a peer to peer network is created between to companies and only individuals who have access rights can create transactions and no one can delete the blocks then the uses of the technology can potentially be endless. It would provide a platform for secure transactions that have traceability for auditing and only give access to the correct recipients.

Use Cases

Considering it’s still in the early stages of the technology and there’s not particular standard on how the methodology should be done, there are many research projects being done by consulting, software, and big box store companies.

Here is just a few projects that jumped out on me:

 

IBM. Blockchain 101 Infographic. Retrieved from https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=XI912346USEN&.

Skip to toolbar