Linda Gurgone is the Lead Business Process Architect in Motorola’s Enterprise Architecture team. She has experience in enterprise architecture, engineering management, NPI core process re-design, engineering development, environment solution portfolio management, IT governance and strategic alignment, software development processes, and Six Sigma.
Motorola is a Fortune 100 Global communications company that is comprised of four businesses:
- Connected home solutions
- Government and Enterprise mobility solutions
- Mobile devices
- Networks
Gurgone explained what a Service Function Reference Architecture is and what its components are. There are two architectures. The first is the physical as-built architecture, which is the IT that is being used, and the “reference architecture” which is the unconstrained, virtual architecture that is the framework and contextual analysis of how the architecture should do its work. The capabilities include:
- Strategic business and planning management
- Marketing and product management
- Supply chain management
- Sales and customer care
- Enterprise support and resource management
A hierarchical and service-flow context describes the unique functions required to serve the business. These include a view of the flow from the major service providers to consumers, independent of the organization and processes. This model is stable and works for any organization. Gurgone said that these models can be bought off the shelf, which is what Motorola did, then configured it to the enterprise.
The basic functional model is defined by the information usage, system performance, system of record and other attributes unique to the business.
The principles of a Service Function architecture include:
- Each service function provides one or more essential services
- Collectively they represent a complete set of capabilities
- Service Functions are independent of the organization
- Service Functions are independent of process
- Service Functions are independent of the degree of automation
- The model is stable and is not intended to change significantly over time
- An information subject is created (owned) by only one Service Function
In order to make the Reference Model work, it has to be made real and applied to the as-built system. To do this, the as-built is linked to the Reference Model. The Business Models include:
- Markets, products, strategy
- Goals, objectives, measures
- Locations, facilities, organization
The Operational Models include:
- Functional hierarchy
- Service flow integration
- Information architecture
- Process models
The Data Models include the Systems Models and the Technology Models. System Models include:
- Function allocation
- Information allocation
- System integration
Technology Models include:
- Infrastructure landscape
- Deployment models
Gurgone pointed out that affinity analysis describes what needs to be done, but not how it should be done. The Reference Model should be reviewed for contextual dependencies and constraints so the big picture can be seen. Then the solutions can be put in where they are needed.
In Service Oriented Process Design, processes are described as a service, a trigger/response, evolving from workflow. It is now a Service Delivery. This brings Service Orientation into the process system.
The important thing to remember, according to Gurgone, is that you are not starting from scratch. You are working from your existing process models. When automating the processes, the concerns are redundancies, overlap, and integration issues in order to get your service components.
The next step in the process is to Reverse Engineer. The functional components and information subjects are pulled out. When doing this, differentiate between function and activity. A function is ‘what’, while an activity is ‘how’.
Then model the service flows between the functions. Create a logical process model before getting into the details. Pay close attention to service delivery and try not to have any circular service flows.
Model the information architecture next. Include only key information that crosses functional boundaries and allocate ownership of information to a single function. Finally, model an event triggering a service that is a group of functional activities and see how it works.
Gurgone said that processes are simple and getting simpler, but it is important to seek the right level to begin and resist going to the activity level too soon. See the whole process as a learning activity and adjust as you go.
