Implementations

The distinctive feature of petroleum businesses is its wide scope. After crude oil or gas extraction, resulting semi-products undergo dozens of transformation stages in supply chains to reach the final customer. Combination of quantity and quality multiplied by external market factors produce price fluctuations that are challenging for world economics. In this regard process management might be carried out to improve supply chain performance and assure the maximum business predictability. However, for such large-scale organizations it requires big effort in operational analysis, process enhancement and process control via information systems which successfully support traditional management in function-oriented organizational structures. This chapter explores the developed engineering matrix that embraces potential methods and tools applicable for oil and gas industry. Additionally, it reveals industrial peculiarities and delivers case studies about Iranian and Hungarian petroleum companies.

People

This chapter discusses the importance of every team in enterprise management. In fact, people are not just employees any more, they are team members. How to form a team and who should be taken in a startup team? What are the main threats of successful team? How to apply collaborative practices to design top-level cross-organizational networks? In this chapter, the authors give recommendations on modern team management and advice on how to increase efficiency of the existing teams.

Processes

The implementation of several modern concepts of enterprise architecture creation is analyzed and real-time business process generation is described. Cloud-based self-generated business service is constructed as a basis of the resulting concept with an aim to increase the flexibility of enterprise and introduce AaaS (architecture as a service). Under particular business request in form of correctly formulated strategic goal the generation of business process model is produced. The result of the generation is cross-cutting business process architecture model, which is approved or rejected/corrected by business owner expertise. During generation all necessary requirements for supporting resources, such as information, know-how, intellectual and professional skills, inputs and outputs, quality and operational risk limitations, control and monitoring, are formed. All formed requirements have to be satisfied by appropriate selections from the cloud facilities and again approved. Finally, after several iterations, the business model will be able to be realized in reality and could be executed with predicted results. Briefly, that means that certain sets of valued and weighted business process replicas are located in clouds and served in clouds. Thus, enterprise architecture becomes a regular service from clouds extending row of SOA in the name of AaaS. In addition, the advanced view on the topic is provided with an attempt to install a virtual SOA torrent that catches services from the internet and makes them available to customers and represents a business service basis for real-time business processes.

Lifecycles

This chapter discusses lifecycle model application for software development. It compares the benefits and shortcomings of different models. The authors argue that there is no universal lifecycle model. For agility, this chapter recommends combining prototyping with the other models. The authors suggest this to achieve a common understanding of the key product features and to reduce project risks. The lifecycle model choice determines project economics and time to market. The model also influences product quality and overall project success. However, product success essentially depends on human factors. The authors analyze the applicability of the lifecycle models to large-scale, mission-critical software systems. Finally, this chapter introduces a methodology. It includes a spiral-like lifecycle and a set of formal models and visual tools for software product development. This methodology helps to optimize the software product lifecycle. It fits large-scale, complex heterogeneous software products.

Antipasti

Nowadays megatrend of Industry 4.0 initiative in complex and dynamic business environments require easy and hands-on methods for enterprise modelling that will be able to recalibrate process's models constantly. Processes are often declared as being “modeled” or “documented” but seldom as being “designed.” This leads to certain afflictions in allocation of the particular resources required for the tasks of process modeling or design. There is perception of process modeling as a routine task, which is structured itself by “modeling terms and conditions” or “modeling agreement,” while “design thinking” is mainly considered as much more less structured and belonging to the artist's nature. Implementation of such models in practice or IT automation does not fit the reality because of misinterpretation from the start of modeling and multiplied on each step of model transformation. In such circumstances any thought about fruitful digitalization looks very abused. This chapter describes a set of tools and techniques for enriching organizational models with semantic information and adjusting them on request. Firstly, this chapter considers an innovative approach for the model binding with relevant documents and experts. Secondly, factors that trigger models' changes using company's information environment (field) are defined. Thirdly, an agile enterprise-modeling framework that automatically adapts to the business situation, creating context-aware working environment for employees, is introduced.

Architectures

This chapter dedicates discussion to certain peculiarities both as cultural and national in modern phenomena of “agility,” which generally bring more destruction in understanding rather than constructiveness. Manuscript's authors are often accused in over-opinionizm versus factography, but in fact, what is a fact of something being described by somebody if not an opinion of that someone, who managed the fact description. It's not just a syllogism since it's a concise logic of our life and here a number of opinions will be excavated from the number of practical consultancy cases. Consultancy teaches consulters that the world is imperfect, but they have to rant knowledge perfection calling to each excellence. There is no true excellence explain except trust in practice. It could be interesting to IT application specialist to get that much of his associations with “agility,” gained in practice, can't sustain yuppie's business vision. As well business will be surprised that his filling of agility is not applicable in digitalization nor directly or implicitly. Here is particular concentration of practical and empirical observations based on two decades of author's business consultancy queries and quests, but that does not imply that reader can't stay with his mind.

Methodologies

In this chapter, the authors discuss software development methodologies. These are adaptive process frameworks adjustable to software product size and scope. They usually include a set of methods, principles, techniques, and software development tools. Every methodology can implement any of the lifecycle models. The authors discuss the difference between formal and agile methodologies. The formal methodologies include more artifacts. For each activity, every role assigned to it produces a deliverable. Agile methodologies are applicable in uncertain conditions. These agile methodologies rely on self-disciplined and self-manageable teams. They are more constrained by human-related factors. As in lifecycle models, there is no “silver bullet” in software development methodologies. Due to rigorous processes and more artifacts, formal methodologies are suitable for large-scale product development. Agile methodologies require special techniques and a high level of discipline. Otherwise, they likely result in a low-quality software.