Virtually every enterprise wants to improve worker productivity through mobility, yet most surveys show that they're...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
dissatisfied with the results of their efforts. The reason? Enterprises don't have a firm grip on what mobile workers need. The first solution should be to turn to enterprise architecture.
First and foremost, organizations should view mobile empowerment as a transformation of a worker-to-business relationship. Then, they should identify new methods that mobility enables. Finally, those processes should be translated to specific mobile application capabilities. Following these steps will improve any mobile project. They might also improve your enterprise architecture model processes overall.
The problem with mobile
The biggest problem with mobile empowerment is that typical strategies don't account for mobility; they account for mobile devices only. A worker, who is supported by a mobile device, doesn't need to get the same information again, which is simply formatted for mobile display. They need to get different information, because the availability of IT support at their activity points changes how they work. Ideally, an enterprise architecture model could step back to business processes and then define its implementation in a mobility-optimized way. This normally can be done through cooperation between enterprise architects and software architects, which is not easy.
Even for nonmobile applications, enterprise architecture business processes should be translated into optimum, practical and technical application frameworks. Software architects and enterprise architects should work together to create a set of technical frameworks to support specific work methods. That step must be carried out every time for optimum mobile empowerment to break any preconceptions about what workers are doing to accomplish business goals so that new, mobile-efficient approaches can be taken. Its success depends on whether best practices in EA modeling were applied.
Enterprise architecture model's approach
There are many enterprise architecture models; each takes a slightly different approach, but in every model there is an explicit transition from business to IT -- from goals and requirements to applications and systems. While it's rarely stated in those terms, all architectures presume that business goals and functions should be abstracted from the methods where they are completed. If a business goal/function, sometimes called a "business process," says "test each circuit for a condition" and "isolate the fault" and so forth, then it gets into methodology and the goal becomes the completion of that task. If it is defined as something like "repair the line," it doesn't presuppose a specific sequence of steps and maintains focus on the overall requirement rather than a specific task.
The challenge many enterprise architects value in driving mobility empowerment will be reduced because pure business requirements are lost or confused. In every enterprise architecture model, there is an implicit or explicit boundary between abstract business process requirements and explicit methods dictated by available IT tools. You have to clean this boundary and ensure that you start with actual business requirements and not with practices set by nonmobile technology. That's likely to involve both enterprise and software architects.
Coordination between enterprise and software architects
Experience suggests that any conversation on optimizing mobile empowerment should start with a description of a current worker-to-IT relationship or current manual process. Then, explore how that process could be altered to take advantage of the unique ability of mobility to tie IT to specific activities.
For example, if a "repair the line" process is being examined, the first step might be generalized as "identify the target for repair," which is generic, rather than "test each circuit" as before. Then, a software architect might indicate that a mobile device tied to a line fault detection system might be able to show a worker the picture of a panel with a correct line highlighted.
This approach can also lead to recognizing new steps. Here, it is implicit that a worker is at a target panel. But supposing that's not the case, can GPS or near-field communications be used to guide that worker to the target panel, where an image showing a proper line could be presented? Will it be desirable, in some cases, to have a worker's position identify tasks that could be done at that location, rather than sending workers to specific points to perform tasks?
This kind of interchange between enterprise architects and software architects isn't unheard of, but it's less common than it should've been if mobile empowerment has to succeed. Essentially, the dialog creates an equation: worker methods are the sum of business processes and mobility options.
When each combination is examined, the one with the best ROI or long-term benefit can be identified, and that should then be the target for implementation.
Enterprise architect's role
The final step to translate new worker methods into a blueprint for mobile development is normally undertaken by an IT organization, software architects and developers. Many users suggest that when enterprise architects are involved in framing new practices for mobile empowerment, they should also coordinate the relationship between software and workers during application design and provide input to the changes necessary in application lifecycle management. New methods demand new worker integration, new compliance and security verification, and new test data. Enterprise architects can be a valuable -- even essential -- resource in optimizing these changes and reducing errors.
Enterprise architects also need to look at mobile empowerment as a lesson from their own practices. Most businesses today have integrated technology tools, not only into methods but into business practices at an enterprise architecture level. This violates the fundamental principle that architecture should describe business processes and not specific methods of work or specific tracks of IT empowerment. Mobility also shows that the boundary between the enterprise architecture model and development is softening to a zone rather than a line, and greater cooperation within that zone is essential to get the right outcome.
Solve IT problems with cloud integration tools
How to design a modern enterprise architecture model